Unravelling PI Planning

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.

Pi Planning

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.

Scaled Agile 5
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


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.

Anshuman Singh

Anshuman Singh

Anshuman brings 9 years of experience in Information Technology products and services in India. Prior to Digité, Anshuman was with Capgemini and Tata Interactive where he was responsible for creating and managing key accounts. Anshuman also plays guitar and is big fan of the works of Oasis.

Other popular posts on Nimble!


  1. Daniel Mas says:

    Hi Anshuman, you (and SAFe) say “The teams refine the Features and the Starter Stories and size them.” but don’t mention how the Features are allocated to the Teams. Do you have any insight on this?

    • Mahesh Singh says:

      Hi Daniel, in our experience, there is no one recommended method for doing this. It really depends on the way companies organize their products and teams. Typically, in cases where there is an existing portfolio of products or apps, teams already own specific products or apps and are responsible for new features and enhancements in those products. Depending on the size of the product (number of modules, tech platform, etc.), teams have module/ epic level ownership – based on factors such as functional or technical expertise/ experience – and therefore might pull (or be assigned) the relevant features during the PI Planning session. We have also seen some of our customers do a high level capacity planning prior to the PI Planning session, just so they have greater clarity going into the PI Planning session. Even at this stage, there may be some decisions made based on the above factors which team will work on which features – and that guides the actual work allocation. Other factors such as capacity needed vs. available may also be in play – but usually, they play a secondary role. Hope this helps.

Get Notified!

Get tips straight to your inbox!

Subscribe To Our Newsletter

Get updates and learn from the best

We are on a Mission to

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives

Subscribe To Our Newsletter

We are on a Mission to #HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives