PI Planning is a cadence-based event, that helps align the teams on the ART to a shared mission and Vision. In SAFe® (Scaled Agile Framework®), it represents an essential event for the Agile Release Train (ART) and is crucial for SAFe existence – if you are not doing it, you are not doing SAFe.
What is PI Planning?
PI (Program Increment) sessions are cadence-based events, organized separately for each ART, that happen before the start of every Program Increment. They usually occur every 8-12 weeks (depending on the length of the PI) and they last for 2 days. Because the length of PI is known, PI Planning sessions can be scheduled well in advance, which can lower cost of travel and logistics and help people on the train to plan and manage other commitments.
The idea of PI Planning is, that everyone plans together; teams estimate what will be delivered and highlight their dependencies with other Agile teams and trains, various requirements and designs emerge, important decisions are accelerated, and teams take responsibility for their own plans. It also provides the time and space to align all stakeholders around the next set of deliverables.
PI Planning sessions represent a great opportunity for various aspects of a solution—business and technical —to be integrated and evaluated together at the same time and help align all teams to a shared mission and vision. If possible, sessions are held face-to-face with physical collocation. In case this is not possible, PI Planning event can be held virtually. Hybrid planning can also be an option, where several teams on ART join remotely and some are present on-site.
PI Planning events are facilitated by the RTE (Release Train engineer) and event attendees include Business Owners, Product Management, Agile Teams, System and Solution Architect/Engineering, the System Team, and other stakeholders.
What are the benefits?
PI Planning event enables personal communication across all team members and stakeholders and fosters cross-team and cross-ART collaboration. It helps align development to business goals, identify dependencies and provides an opportunity for just the right amount of architecture and Lean User Experience (UX) guidance. It accelerates decision-making, matches demand to capacity and helps eliminate excess work in process (WIP).
What are the inputs and outputs to PI Planning?
The inputs for the PI Planning process are well defined business context, roadmap, vision and top 10 Features of the Program Backlog. The outputs, on the other hand, are two. The first one is a set of Team and Program Committed PI Objectives. These are a set of SMART objectives that are created by each team with the business value assigned by the Business
Owners. The second output is the Program Board which helps visualize and highlight the new feature delivery dates, feature dependencies among teams and all the important Milestones.
How to prepare for the event?
Preparation for such an event calls for organizational, content and logistic readiness.
What are pre- and post- PI Planning meetings?
Pre- and Post- PI Planning meetings provide a great opportunity for open communication, alignment, cross-ART coordination and synchronization of ARTs and Solution Train vision through ART and Solution PI Objectives. They help identify dependencies, match solution demand to ART capacities and promote team building across the whole Solution Train. Both meetings are attended by Solution stakeholders, including Solution Train Engineer (STE), Solution Management, Solution Architect/Engineering, solution System Team, and Release Management Representatives from all the ARTs and suppliers, usually Release Train Engineers (RTEs), Product Management, System Architect/Engineering, Customers, and other primary stakeholders (Source: Scaled Agile, Inc.).
Pre-PI Planning meeting is held before PI Planning and its purpose is to coordinate input objectives, Milestones and business and solution context for the PI Planning session. Post-PI Planning happens after PI Panning event and its purpose is to assess and remove Work in Process (WIP) and integrate the results of PI Planning into Vision and Roadmap for the larger value stream. At the end of post PI Planning there should be an agreement on a set of PI Objectives at solution level that need to be implemented by the end of Program Increment and demoed at the next Solution Demo (Source: Scaled Agile, Inc.).
Inputs to pre- and post-PI planning include the Solution Roadmap, vision, Solution Intent, and the top Capabilities from the Solution Backlog. Outputs, on the other hand, include three primary artifacts (Source: Scaled Agile, Inc.):
- A set of aggregated specific, measurable, achievable, realistic, time-bound (SMART) PI objectives for the solution
- A solution planning board, which highlights the capabilities, anticipated delivery dates, and any other relevant milestones for the solution
- A confidence vote (commitment) to the solution PI objectives
PI Planning’s Standard Agenda
PI Planning event takes place over two days, although it could be extended to accommodate planning across multiple time zones in case of distributed/remote teams. PI Planning agenda is standard for all PI Planning events. Event includes all members on ART and it occurs within the Innovation and Planning (IP) Iteration. Holding the event during the IP iteration avoids affecting the scheduling, or capacity of other iterations in the PI. Examples of agenda for Day 1 and Day 2 can be seen on below graphics.
What happens during Team Breakouts?
TEAM BREAKOUT #1:
During the first breakout teams estimate their capacity for each Iteration and identify the backlog items they will likely need to realize the features. Each team also creates their draft plans, visible to all, iteration by iteration.
TEAM BREAKOUT #2:
During the second breakout teams continue planning based on their agenda from the previous day, making the appropriate adjustments. Teams finalize their objectives for the PI, Business Owners circulate and assign business value to PI Objectives from low (1) to high (10). PI Objectives are business summaries of what each team intends to deliver in the upcoming PI. They usually relate to Features in the backlog, but can also include important Milestones, Enable Feature that supports the implementation or major refactoring.
Teams finalize the Program Increment plan, consolidate program risks, impediments, and dependencies. They also define uncommitted objectives that provide the capacity and guard band needed to increase the reliability of cadence-based delivery. Because they are not included in commitment, they make commitment more reliable and help improve the predictability of delivering business value. As a rule, if a team has doubts in meeting a PI Objective, or the Objective has many unknowns, it should be moved to uncommitted.
How are Program Risks addressed?
After the team breakouts and when all plans have been finalized and presented, it is time to discuss all remaining program risks and impediments that could impact team’s ability to meet their objectives. They are resolved in front of the whole train. One by one, the risks are read, discussed and addressed with honesty and transparency, and then categorized into one of the following categories:
- Resolved – Has been addressed. No longer a concern.
- Owned – Someone on the train has taken responsibility.
- Accepted – Risk is understood and accepted – If it occurs, release may be compromised.
- Mitigated – Team has plan to adjust as necessary.
Each risk is then added into a corresponding quadrant of the ROAM sheet for the program.
What is the Program Board?
Program Board is the most important output of the PI Planning event. It shows Feature delivery, all the dependencies, and important Milestones. Different colors are used for different elements, for example:
- Orange sticky notes: Program milestones = important events that are happening in certain Iteration, such as trade shows, market releases …
- Red strings: If features are connected with red strings, they cannot be delivered until multiple teams complete their dependencies (Dependencies requiring Stories or other Dependencies to be completed before the Feature can be completed)
- Features placed in a team’s swim lane with no strings can be completed independent of other teams
- Blue sticky notes – Features
- Red Sticky notes – Significant Dependencies
Why is first PI Planning the most important?
First PI Planning event makes the biggest impression on all members of the ART. It creates visibility, confidence in the commitment of Lean-Agile leaders to the Transformation and generates a short-term win. It also helps all the members on the ART to meet each other, connect and assume responsibility for planning and delivery.
Who should attend and be involved in PI Planning event?
In a PI Planning, there are 5 key roles: Release Train Engineer (RTE), Product Managers, Product Owners, Scrum Masters and Agile Teams.
Release Train Engineer
Release Train Engineer, a servant leader and coach to the ART, plays a crucial role, as he is responsible for planning and is the one who facilitates the event. RTE establishes and communicates dates for all PI Planning events in advance. He prepares everything for the event (including holding post and pre PI Planning meetings), manages risks, impediments, creates Program PI Objectives from Team PI Objectives and publishes them, tracks progress towards expected goals and ensures strategy and execution alignment. In the beginning of the PI Planning event RTE presents the planning process and expected outcomes. On top of that he facilitates System Demos, Management Review, Problem-Solving Workshop and retrospective.
Product Manager
Product Manager is the one who understands and supports portfolio work and manages and prioritizes the workflow. He knows and understands customers’ needs and can validate solutions and he takes part in pre and post Pi Planning meetings. During the PI Planning, Product Manager presents top 10 upcoming Features, Program vision and explains any important Milestones that will happen during coming Program Increment. When Teams create the Draft plans, they review them, and after Management Review & Problem-Solving Workshop, they communicate any possible changes to the planning and scope. At the end of PI Planning Product Manager updates the roadmap with Program Objectives.
Product Owner
Product Owner’s responsibilities include maintaining and prioritizing the Team Backlog and Iteration Planning. During PI Planning, POs have content authority to make decisions at the User Story level during Team Breakout sessions, they help their Teams to define, estimate and sequence stories and assist them at drafting their PI Objectives. They also take part in Team Confidence Vote and are responsible for communicating visions and goals form higher managers to their teams. On top of that, PO’s responsibilities include evaluating team progress, reporting on key performance metrics and communicating status to stakeholders.
Scrum Master
Scrum Master acts as a servant leader to PO and Agile Team. Read more about Scrum Master’s role in the article How to become a Scrum Master?
Scrum Masters prepare everything for the PI Planning event and System Demos. They assist their teams with estimating their capacity for Iterations and finalizing PI Objectives, they make sure everything is time-boxed, manage dependencies and facilitate Team Breakout Sessions. Scrum Masters also take part in Confidence Vote and help teams reach consensus.
Agile Teams
During PI Planning, Agile teams participate in Breakout sessions. During these sessions, they create and refine user stories and acceptance criteria (alongside their Product Owner) and adjust the working plan. They identify risks and dependencies, draft and finalize Team PI Objectives and participate in the Team Confidence Vote.
What to do when teams are distributed?
How is the PI Planning realized if it is not possible to hold a face-to-face event (for example because of the pandemic, such as one, created by Covid-19)? Read more in the article Distributed PI Planning with SAFe.
