PI Planning is a key practice in SAFe (Scaled Agile Framework). It helps organizations align their work with their business goals and objectives.
In this article, I’ll explore the most important characteristics of PI Planning in Scrum, making it easier than ever to plan how to deliver value to your customers at scale.
What is PI Planning?
PI Planning, or Program Increment Planning, is a key event in SAFe, which enables organizations to deliver large and complex solutions.
It is a 1-2 days collaborative meeting, also known as Big Room Planning, where all members of an Agile Release Train (ART) come together to plan the work they will accomplish in the next Program Increment (PI). PI Planning is a timeboxed iteration of work (usually around 3 months).
PI Planning allows teams to:
- establish a shared understanding of the objectives and priorities of the upcoming PI,
- break down the work into smaller pieces,
- create a detailed plan for how to get the work done,
- identify and resolve any dependencies or constraints that may impact the team’s ability to deliver value.
This also fosters a shared sense of ownership and accountability for the work ahead. It is also an opportunity for teams to get feedback and guidance from stakeholders, and to ensure that the work they are doing aligns with the needs and priorities of the business.
As the SAFe website states: “PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe”.
An example of a PI Planning session at a large financial organization.
Organizing a PI Planning session
As I mentioned earlier, PI Planning involves all members of the ART (Agile Release Train), but first, let’s see what ART is.
What is ART? The Agile Release Train
An Agile Release Train is a long-lived, cross-functional team of Agile teams who work together to deliver a large and complex solution in a predictable and iterative way at the Program Level.
The ART provides a structured approach for organizing and coordinating the work of multiple Agile teams (recommended between 5 to 12 members for an optimal use of resources and communication channels) and is guided by a shared mission and vision. It is responsible for delivering value to the customer in the form of a releasable increment at the end of each Program Increment (PI).
Who participates in a PI Planning session
I like to say that “ART are those teams who plan and deliver together”. Unfortunately, in a complex organization, the ART teams may not be fully autonomous to deliver. They have dependencies with other teams outside the ART. That’s why we must also involve those external teams in the PI Planning, which is also an excellent opportunity to improve the overall efficiency of our organization.
PI Planning is a highly collaborative event that involves all members of an ART, from Product Management (responsible for defining the vision and goals of the program increment) to all Agile Team members (responsible for delivering the solution).
During PI Planning, they work with the Product Owners to break down the large items into smaller ones and create a detailed plan for the upcoming PI. This is the part that usually receives more criticism because it’s an apparently inefficient process as it is a big number of people interacting at the same time and in the same place. In my experience, this breakdown must be considered as an early refinement of big features that eventually will be developed by the team. It’s an excellent opportunity to avoid planning work that is not viable, too expensive, or has too many dependencies. Everyone is in the same room and decisions can be made very quickly.
That’s why SAFe also fosters that other roles involved in the ART attend this event, such as stakeholders, system architects, etc. They can help identify or mitigate risks, which is also one of my preferred activities made during the PI Planning.
RTE: The role of Release Train Engineer
SAFe defines the role of RTE (Release Train Engineer) as a kind of Scrum Master for the whole ART. The main responsibility of this RTE is to facilitate the PI Planning event. The rest of Scrum Masters and Agile coaches, helping the teams involved in the ART, should also act as organizers and facilitators of the event, as it is a lot of work in a concentrated amount of time.
Schedule for the PI Planning
SAFe recommends scheduling PI Planning in a period between Program Increments called the Innovation and Planning Iteration. It acts as a buffer to schedule those activities that are usually missed or postponed during the Product Increment, like prototyping, training, retrospectives, or planning for the next PI (i.e. the PI Planning). In big organizations, this period can also be useful to create new teams or run kick-offs or inception workshops.
Depending on the size and complexity of your ART, you may need 2 days for the PI Planning meeting. Teams can create a draft of their plans during the first day and be confirmed during the second day, using the time in between for clarification activities, and risks and dependencies resolution with the upper management. These dependencies can be visualized with a variety of tools, from boards and woolen threads (like the one in the picture) to spreadsheets collecting all the dependencies between teams.
A board visualization of dependencies between tasks and sprints
The importance of logistics
As mentioned, the PI Planning is a big event – it can easily have more than one hundred people involved – and still has to be effective as it has a big impact on the work of many teams for a period of three months.
It needs some organization, especially everything related to logistics. You’ll need a room big enough to host all attendees at the same time, transportation (if they don’t usually work in the same building as the event), Wi-Fi, some food and beverages, etc.
This is another criticism for the PI Planning — the logistics needed. There are partial solutions, like running the event in a remote environment. Even SAFe suggests an agenda for a Distributed PI Planning. Going remote but keeping the event synchronous should extend the overall duration.
A more radical but effective alternative is transforming the PI Planning from synchronous to asynchronous. Instead of having the PI Planning meeting as the start and the end of the planning process, it becomes a deadline, when all the planning should be confirmed, i.e. all teams should have their backlogs already prioritized; risks and dependencies should be managed as well. If you are going for this approach, you must watch the progress as this requires more discipline than the synchronous event.
Conclusion
PI Planning is an essential part of SAFe but must be chosen wisely. If your organization is too simple, PI Planning can be too expensive (especially in terms of logistics) and introduces delays that can be avoided using lean approaches.
On the other hand, if your organization is too complex, PI Planning will be difficult to implement. However, you should embrace the opportunities to improve your organization by following those signals that may work as a stopper of your PI Planning.
