PI Planning Guide
A practical guide to Program Increment Planning in SAFe — from preparation to the confidence vote.
What Is PI Planning?
Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Scaled Agile Framework (SAFe). It brings together all the teams on an Agile Release Train (ART) — typically 50 to 125 people — to align on a shared mission, identify dependencies, and commit to a set of PI Objectives for the upcoming program increment.
A Program Increment is a fixed timebox — usually 8 to 12 weeks — during which an ART delivers incremental value in the form of working, tested software and systems. PI Planning sits at the start of each PI and sets the direction for all teams involved.
Unlike a traditional sprint planning session that focuses on a single team over a 1–2 week sprint, PI Planning is a large-scale coordination event. It replaces weeks of ad-hoc meetings, email threads, and delayed alignment with a concentrated two-day forum where everyone — from engineers to product managers to business owners — collaborates in real time.
The output of PI Planning is a set of team PI Objectives: a prioritised list of business and technical outcomes each team commits to delivering during the increment, along with a Program Board that visualises cross-team dependencies and key milestones.
Who Participates
PI Planning is an all-hands event for the ART. Attendance is not optional — the whole point is to align everyone simultaneously rather than relay information through a chain of intermediaries. Key roles include:
Release Train Engineer (RTE)
Facilitates the entire event, keeps the agenda moving, resolves impediments, and guides teams through team breakouts, the draft plan review, and the final plan review.
Product Management
Presents the vision and the top features for the PI. They own the ART backlog and prioritise what gets built so teams can plan their work accordingly.
Business Owners
Senior leaders and stakeholders who attend to provide business context, answer questions, and validate that team objectives align to business value. They assign business value scores to team PI Objectives.
Agile Teams
Every team on the ART — including developers, testers, UX designers, and Scrum Masters — attends as a group. They do the actual planning work during team breakouts.
System and Solution Architects
Guide technical decisions, present architecture runway needs, and ensure teams plan with a sustainable technical foundation.
Product Owners
Work within their team breakouts to negotiate features and stories into team iterations, refining the team backlog in real time based on capacity.
The 2-Day Format
SAFe prescribes a standard two-day agenda for PI Planning. While organisations adapt the timing, the structure below represents the canonical flow.
1Day 1 Morning — Vision and Context
The event opens with a business context presentation from senior leadership, followed by the product management vision. Teams hear about the current state of the portfolio, the strategic themes driving the PI, and the top features and capabilities prioritised for the increment. Architects present any Enabler work needed to support the planned features.
2Day 1 Afternoon — Team Breakouts (Round 1)
Teams break out into their groups to begin detailed planning. They estimate their capacity for each sprint in the PI, identify the features and stories they can commit to, identify cross-team dependencies, and draft preliminary PI Objectives. Product Owners and Business Owners circulate to answer questions and negotiate scope.
3Day 1 Evening — Draft Plan Review
Each team presents their draft plan to the full ART — typically 3 to 5 minutes per team. Business Owners score the team PI Objectives for business value. The RTE captures risks and impediments on a shared board. Management adjusts priorities where needed.
4Day 2 Morning — Team Breakouts (Round 2)
Teams incorporate feedback from the draft plan review and adjust their plans. They resolve dependencies identified the previous day, refine their PI Objectives, and update their Program Board entries to reflect any scope changes. This is the time for negotiation between teams to resolve blockers.
5Day 2 Afternoon — Final Plan Review & Confidence Vote
Teams present their final plans. The RTE facilitates the Management Review and Problem-Solving session to address risks. The event closes with the confidence vote — a fist-of-five or equivalent poll of the entire ART. If the average is below 3, teams continue to resolve concerns until confidence rises. A successful confidence vote officially starts the PI.
Preparation Before the Event
The quality of a PI Planning event is determined largely by the preparation done in the weeks leading up to it. A poorly prepared PI Planning results in teams spending breakout time hunting for missing information rather than planning.
Product Management should enter the event with a prioritised and refined ART backlog. Features should be written clearly enough that teams can estimate and plan without requiring extensive clarification. The vision presentation should be prepared and rehearsed.
Teams should pre-calculate their capacity for each sprint in the PI using historical velocity data and accounting for planned time off, holidays, and other commitments. Team backlogs should be refined with enough user stories to populate at least the first two sprints.
Logistics matter too. Whether the event is in-person or remote, the tooling and environment should be tested in advance. Physical Program Boards, sticky notes, and markers should be available for in-person events. Digital collaboration tools like Miro, Jira Align, or Rally should be configured and accessible for remote sessions.
Risks and Dependencies
One of the most valuable outputs of PI Planning is the explicit identification and tracking of cross-team dependencies and programme-level risks. SAFe uses the ROAM framework to classify risks captured during the event:
Resolved
The risk has been addressed during PI Planning and is no longer a concern.
Owned
Someone takes responsibility for managing the risk through the PI.
Accepted
The risk is understood and accepted as an inevitable part of the work.
Mitigated
Steps have been planned to reduce the impact or likelihood of the risk.
Dependencies between teams are visualised on the Program Board using strings or arrows connecting planned work items across team rows and sprint columns. Identifying these connections early allows teams to negotiate delivery order and flag blockers before they derail the PI.
Remote PI Planning Challenges
Running PI Planning for distributed teams introduces a layer of complexity that organisations must proactively manage. The energy and spontaneous collaboration of an in-person room of 100 people is genuinely difficult to replicate online.
Time zones are the most obvious challenge. A single PI Planning event spanning two full days can span 16+ time zones on a global ART. Many organisations compromise by anchoring the event to overlapping business hours, which may mean early starts or late finishes for some participants. Others split the event across three or more shorter days to reduce fatigue.
Digital Program Boards must replace physical boards. Tools like Miro, Mural, or SAFe-specific tooling such as Jira Align can replicate the visual stickiness of a physical board, but they require familiarity to use effectively under time pressure. Pre-training participants on the tooling before the event is essential.
Breakout facilitation becomes harder remotely. Scrum Masters and RTEs must be deliberate about checking in on breakout rooms, and teams need a clear shared space for their plans. Having a dedicated video channel per team and a main plenary channel for the full ART helps manage the flow.
The confidence vote, which is instinctive in a room — hands raised, fingers showing — requires a deliberate polling mechanism online. Use a live poll tool or dedicated estimation tool to gather votes and display results in real time.
Tips for a Successful PI Planning
The teams that get the most from PI Planning share a few common practices. First, the vision and prioritised features must be available to teams at least two weeks before the event. Surprises during Day 1 presentations lead to poor planning in the breakouts.
Keep the vision and context presentations concise. A two-hour keynote before teams can start planning saps energy. Aim for 60 to 90 minutes of context-setting, then get teams into breakouts quickly.
Business Owners must be engaged and available throughout both days. Their role is not to observe — it is to answer questions, trade off scope, and assign business value. When business owners disappear after Day 1 morning, team plans lose alignment with business intent.
Inspect and Adapt after every PI Planning. After the PI completes, the Inspect and Adapt workshop reveals what went wrong. Common patterns — consistently overcommitted plans, unresolved cross-team dependencies, or poor capacity estimation — should feed directly into improvements for the next PI Planning.
Finally, protect the two-day commitment. PI Planning only works when the whole ART is present and focused. Allowing participants to join partially, skip breakouts, or multitask during plenary sessions degrades the quality of the output and signals that the ceremony is not a priority.
Start estimating your PI stories.
While the PI planning tool is in development, use ScrumChamps planning poker to estimate the user stories that will feed your team's PI objectives. Or explore our blog for more agile guides.