Long-term strategic planning is a remnant of the past that can’t reflect the fast pace of the digital world we live in today. Companies that implement an Agile approach, shift to delivering results in a short time all the while remaining flexible enough to adjust to any changes as they come. This calls for a completely different attitude in planning with the focus on short term goals that spin out for no longer than a few weeks or even days. Moreover, Scaled Agile helps manage the growing complexity and scaling of businesses to any size and number of distributed teams introducing new methods and tools, one such being Program Increment planning or PI planning for short.
PI planning brings together multiple agile teams for an event that’s like an exciting adventure in and of itself: meeting colleagues from distributed teams, working together in close proximity, as well as socializing and team building in an informal atmosphere. It’s a principle on which the Agile Release Train operates.
Each agile team of 5-11 individuals is a functional unit that is one of many to comprise the Agile Release Train (ART). The ART, alongside stakeholders, takes upon the responsibility of aligning all the teams involved in developing, delivering and supporting the product post-release. An ART is aimed at providing a continuous stream of value to the end-user.
In Scaled Agile Framework (SAFe), it is typical to plan the realization of an entire project in program increments. This is where PI planning comes into play. A common practice is to bring all agile teams together for a PI planning event in the course of which the teams work with the program backlog, team members plan out their scope of work, determine dependencies and evaluate program risks.
This being said, PI planning event achieves alignment and transparency across multiple teams and helps have them commit to a common mission. Distributed teams may be lacking business context and product vision, only ever looking at one level of the complex problem at a time. Bringing people together to one location, having them sit face-to-face and establish the connection of working on a common goal, helps every team member puzzle the pieces together and get the full picture.
Risk mitigation is another big focus in planning for the next PI. This entails identifying and evaluating the risks that may arise in the execution of the plan. Program risks may hinder the teams in meeting their objectives. The teams address and discuss each risk, coming up with probable solutions right on the spot.
Resolving and mitigating these program risks forms a crucial part of the PI planning event.
PI planning generally takes place over the course of two days, starting with presentations explaining the business context as well as product and architecture visions to be executed in the upcoming PI. Then the teams have breakout sessions where they work on planning out their work for the next program increment. After that, the teams present their final plan, define risks and have a confidence vote. At the end of the PI planning, the teams are expected to deliver two outputs which are PI objectives and the program board.
A big part of PI planning events is to have people come to one location and join efforts in working on the plan for the next PI. That being said, under certain circumstances, there’s no way to bring close to a hundred people across multiple locations to one spot for a few days of productive planning and teambuilding. These can be travel restrictions, financial constraints, difficulties in coordinating large teams or the pandemic. In this case, remote PI planning is something worth giving a try. There are real-life examples of companies successfully organizing and conducting remote PI planning events popping up now and again. It takes some more dedication and organizational skills, strong technical support and finding the right tools but it’s something worth looking into as a possibility.
PI planning is a typical part of SAFe, however, businesses that don’t work in the IT industry or don’t use the Agile methodology can also benefit from it. It all comes down to the specificity of the team and the project in question. Some indicators that you don’t need PI planning are:
In short… Do not scale if you can avoid it.