There is a quote introducing PI Planning content on the Scaled Agile Framework website. The quote reads “There is no magic in SAFe® except maybe for PI Planning”. In this blog, I aim to take a closer look at the PI Planning ceremony and in the process maybe gain more clarity on why it is held in such high regard.
Img Src: Youtube.com/VanceLowe
Most organizations that implement SAFe® do not implement it in its entirety. But if there is one common denominator between all SAFe® implementations, then it has to be the PI Planning. So what is PI Planning? And what does the ‘PI’ in PI Planning mean?
Well – PI stands for Program Increment. A Program Increment is a fixed timebox of 8 to 12 weeks (default being 10 weeks as recommended by Scaled Agile Inc.). The 10 weeks’ time-box encapsulates 5 Agile Sprints or Iterations with each spanning 2 weeks. The 10 week PI ends with PI System Demo where the work delivered during the PI is showcased to the stakeholders. (It is useful to note here, that a PI is an increment of a full Program. A Program is where teams and other resources are applied to some important, ongoing development mission. A Program consists of multiple Program Increments.
As the PI has 5 iterations with multiple teams working in cadence to achieve a common vision, it is important for these teams to assemble and plan out the course of action for the entire PI duration. The meeting also helps the teams understand any dependencies amongst themselves and any risks to be addressed. This meeting is referred to as PI Planning. It is an elaborate and detailed meeting and has a duration of 2 days for a 10 week PI.
So what goes into a PI Planning?
The Program Vision and Program Backlog are two key inputs that are essential for conducting a PI Planning meeting. The Vision provides the context to the entire team on why and how the work being done in the PI will help in the delivery of the overall Solution. The Program Backlog comprises of the top 10 Features ranked by Priority and accompanied with a short description of the Business Benefit that the Feature would beget.
The Program Backlog is owned by the Product Manager who is also responsible for ensuring that it is ordered as per business priority based on market reality and other environmental factors. The top 10 Features are also accompanied with Starter Stories (where many stories may be missing, many need to be broken down, or are duplicates in other team’s backlogs) which enable teams to kick-start their plan for the PI.
Img Src: Scaled Agile
PI Planning
The PI Planning is meant for the entire team allocated to the Agile Release Train and everyone is expected to attend it. If some of the team members are at other locations, they need to join in remotely. The PI Planning meeting is divided into different sessions held over the 2 day period.
The PI Planning meeting is organized by the Release Train Engineer (RTE, also called the Scrum Master of the Agile Release Train). The RTE presents the Vision and the top 10 Features in the inaugural session of the PI Planning. After that, all the teams get into their respective breakouts where they estimate their respective velocity for, if not all the 5, at least the first 2 iterations. The teams refine the Features and the Starter Stories and size them. At the end of the first day, the teams get together with the Business Owners, System Architects and other stakeholders for clarifications and to highlight their understanding.
On the second day, the teams again get into a break-out session and further refine their respective backlogs. Each team formulates a list of objectives called Team Objectives and the Business Owners give each of the objectives a Business Value score. The Business Value score is a number between 1 to 10 (10 for the highest Business Value, 1 for the lowest). More than one objectives can have the same Business Value score.
After this, each of the team presents their plan to the entire assembled group. The plan highlights the risks identified, the dependencies foreseen, and the agreed-upon objectives along with their Business Value. Once each of the teams has completed this presentation, an aggregated list of team objectives is presented and an aggregated list of Program risks is also compiled.
The team discusses each of the risks and addresses them based on the ROAM (Resolved, Owned, Accepted, Mitigated) mechanism. Finally, there is a vote of confidence where each team gives their score (between 1 and 5) on how confident they are of attaining the various objectives. If any team votes lower than a score of 3, then they must voice their concerns which are deliberated upon by the entire group. The concern might add to the list of risks or require some re-planning or simply be informative. If necessary the teams rework their plans until a high confidence level can be reached.
Outputs from a PI Planning
The outputs of a PI Planning meeting are the following –
- A list of Team Objectives with Business Value, where objectives are business summaries of what each team intends to deliver in the upcoming PI.
- Also, there are Stretch Objectives that each team may have opted for in case they are able to complete their work and some velocity is left.
The team objectives are aggregated and refined to form the overall Program PI Objectives with Business Value. This is done by the Release Train Engineer after the PI Planning meeting is over and not during the meeting.
- We also gain an insight into each team’s velocity for Iteration 1 and Iteration 2 at the minimum, along with the User stories with Size identified for these iterations that the teams will work on.
- An important output of the PI Planning is the Program Dependency board which depicts the Features/ Stories, any Dependencies, and the Milestones. Architects and UX team members play a key role to help identify these dependencies.
- PI Planning also gives us a list of Risks identified and how they have been addressed through ROAM (Resolved, Owned, Accepted, Mitigated) mechanism.
Main Roles involved in PI Planning
The key roles and their function during the PI Planning are highlighted below.
- Business Owner – provides the Business Value and approval to Team PI Objectives
- Product Manager – provides the Top 10 Feature backlog (prioritized)
- RTE – presents the planning process and the expected outcomes
- Product Owner and Scrum Masters – to enable Team breakouts and Feature to Story decomposition
- Agile Teams – for breaking the Features into User Stories during the Team breakouts, identify/ address risks and for giving the all-important confidence vote
- System Arch/ Engineering – to help establish inter-team dependencies and risks
Epilogue
The PI Planning meeting serves the important function of bringing the entire ART team together and helping them gain a unified perspective on the work they are going to accomplish.
The teams get to hear from the Business Owners – the organizational leaders – about how the PI being planned will help the organization get closer to their overall goals and what is the envisioned future of the Solution being delivered.
On a more mundane note, the teams are able to highlight the interdependencies and how they plan to address them successfully. Having formulated the PI objectives, the teams have a sense of ownership to deliver them.
The PI Planning meeting is organized in the 5th iteration of the PI which is the Innovation and Planning Iteration and thus does not need to be scheduled on an additional timeline. It quenches the need for the perspective that the teams often desire but rarely obtain. It distributes planning and control of work to the teams who are ultimately responsible for delivering.
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
