PI Planning: How SAFe Teams Plan a Program Increment

PI Planning is the two-day event where every team on a Scaled Agile Framework (SAFe) Agile Release Train builds a shared, dependency-aware plan for the next Program Increment, then votes on how confident they actually are in it. It's the single event that makes SAFe work as a coordination model instead of just a chart full of new titles.

It's also the event most organizations get wrong. Teams show up unprepared, the agenda turns into a status meeting, the confidence vote gets rubber-stamped at five fingers by people who never raised their real concerns, and the program board gets photographed once and never looked at again. None of that is inherent to PI Planning. It's what happens when the event runs on autopilot instead of on the discipline it was designed around.

Key Facts

• Scaled Agile documents PI Planning as "a cadence-based event for the entire ART," held every 8 to 12 weeks and typically run as a two-day event, in person or distributed. Source
• Business Owners score each team's PI objectives on a 1 (lowest) to 10 (highest) business value scale, near the end of the event, after every team has finalized its plan. Source
• The event closes with a fist-of-five confidence vote across the whole Agile Release Train; a vote of two fingers or fewer obliges the group to discuss and adjust the plan before it can formally close. Source
• Scaled Agile added updated facilitator guidance to its PI Planning documentation in March 2026, and confirms real-time virtual planning "has proven effective when physical presence is not possible, as long as all members of the ART participate." Source

What a Program Increment Is (and Why PI Planning Exists)

A Program Increment (PI) is the timebox a SAFe Agile Release Train (ART) plans, builds, and evaluates against together. As our SAFe overview covers, a PI runs 8 to 12 weeks, and most organizations settle on 10-week PIs made up of five two-week iterations, with the last one set aside as an Innovation and Planning (IP) iteration for hardening, exploration, and PI Planning itself. Scaled Agile's own documentation confirms the same 8-to-12-week cadence and the two-day event format for PI Planning (source).

PI Planning exists because a Program Increment is too big a unit of work to coordinate through email threads and status updates. When 50 to 125 people across five to twelve teams all need to ship toward the same increment, somebody has to get everyone in a room (physical or virtual) at the same time, walk through the same context, and let each team commit to a plan that accounts for what every other team is doing. That's a fundamentally different exercise than traditional project planning, where a project manager builds a schedule and pushes it down to contributors. PI Planning pushes the planning work out to the teams doing it, then reconciles the results in the room.

That's also why PI Planning doesn't scale down well. Teams running lighter coordination models, with less ceremony and more reliance on shared engineering practices, solve the multi-team synchronization problem differently. PI Planning is the right tool when you specifically need dozens of teams committing to the same fixed increment on the same day.

Who Attends PI Planning and What They Do

Everyone on the ART attends, which is the point. But a handful of roles carry specific responsibilities before, during, and after the event.

Two roles are worth calling out because organizations often blur them. SAFe splits Product Management (program-level, owns the feature backlog, presents context on day one) from the Product Owner (team-level, owns the team backlog, works inside a single team's breakout). If your organization is still deciding how to divide that work, our Product Owner vs Product Manager breakdown covers it directly, and PI Planning is exactly where the split gets tested: Product Management sets direction on day one, Product Owners turn it into a committed plan on day two. Teams that skip this distinction tend to end up with one overloaded person doing both jobs badly during the event.

Team-level agile ceremonies, like daily standups and retrospectives, don't pause during PI Planning. They fold into the two-day agenda instead, since the event itself is really a scaled-up planning ceremony that runs at the program level rather than the team level.

The Two-Day PI Planning Agenda

The standard SAFe agenda is built so each block produces exactly what the next block needs: business context feeds the draft plan, the draft plan feeds the management review, and the management review feeds the final commitment and confidence vote. Organizations adjust the exact timing to their own calendar, but the sequence below is the widely used structure (source).

Day 1: Context and Draft Plans

Day 2: Adjustments and Commitment

Team breakouts are where sprint planning-style mechanics actually happen: teams size features against story points, often using planning poker to reach a shared estimate, and check the total against their known capacity before committing to anything. The difference from a normal sprint planning session is scale and visibility: everyone's draft plan gets reviewed by every other team in the same room, not kept inside one team's backlog.

What PI Planning Produces: Objectives, the Program Board, and the Risk List

PI Planning isn't just a meeting, it's a production process. Three artifacts come out the other end, and none of them are optional if you want the next PI to run on anything other than hope.

Committed objectives count toward the ART's predictability measure at the end of the PI; uncommitted ones don't, because the team has flagged real uncertainty about whether external factors will let the work land (source). That distinction matters more than it looks: a team that marks every risky objective as committed just to look confident is setting itself up for a bad predictability score, and a team that marks everything uncommitted to avoid accountability is gaming the measure the other direction. Honest scoring is the whole point.

Objectives flow into the team and program backlogs as the PI runs, and many ARTs track delivery against the plan with a PI-level burnup, since a burnup chart shows both completed scope and any scope added mid-PI, which a burndown alone hides. The program board is the artifact most likely to get built once and forgotten. Teams that keep PI Planning honest treat it as a living document, updated at ART sync every iteration, not a photo taken at the end of day two.

ROAMing Risks: How Teams Clear the Board

Every PI Planning event surfaces risks that individual teams can't resolve on their own, things like a shared platform team being overcommitted, an external vendor dependency with no confirmed date, or two teams both assuming they own the same integration point. SAFe handles these with ROAM, a four-way categorization every program risk gets sorted into before the plan is considered final (source).

The reason this happens live, in the room, on day two, is that the people who can actually resolve or own a given risk are all physically or virtually present at the same time, which almost never happens again until the next PI. A risk that gets silently added to someone's backlog after everyone has left the event usually just sits there. ROAMing it in front of the whole ART forces a real decision. This is the same discipline behind good project risk management: every risk needs an owner and a next action, not just a place to be written down. Teams already running a RAID log for ongoing project risk will recognize the pattern; ROAM is that same accountability applied specifically to the risks a Program Increment surfaces.

The Confidence Vote, and What a Low Vote Means

PI Planning closes with a fist-of-five vote. Every ART member holds up one to five fingers at the same time, showing how confident they are in the committed plan as a whole, not just their own team's slice of it.

A vote of two fingers or fewer from anyone in the room obliges the group to discuss and adjust the plan before the event can formally close (source). That's a deliberately public mechanism. The vote has to happen where a low score can't be quietly absorbed into an average and ignored, and where pressuring a dissenter into raising their hand higher defeats the entire point of asking. An RTE who treats a string of twos and threes as a problem to manage around the vote, rather than a signal to act on, has turned the confidence vote into theater.

In practice, a low vote usually traces back to one of a few causes: a dependency that never got resolved during the risk review, a team that was quietly overcommitted during breakouts and didn't push back, or a business context that changed between draft and final plan review without anyone re-explaining it. The RTE's job in that moment is to find out which one it is and fix the actual cause, not to re-run the vote until the number looks better.

Preparing for PI Planning: The Weeks Before the Event

PI Planning fails or succeeds mostly in the weeks before it happens, not during the two days themselves. Scaled Agile frames preparation as three kinds of readiness: organizational, content, and logistics (source).

Skipping content readiness is the most common failure point, because it's the easiest to underestimate. A vague or unprioritized program backlog means teams walk into breakout sessions with nothing concrete to size, and the whole first day slides toward status updates instead of planning. If your program backlog isn't in shape two weeks out, that's the signal to push the event, not to hope teams sort it out live.

Distributed and Remote PI Planning

Scaled Agile is explicit that PI Planning doesn't require everyone in one physical room: "real-time, virtual, and face-to-face planning has also proven effective when physical presence is not possible, as long as all members of the ART participate" (source).

That participation clause is the whole game. A distributed PI Planning event that works has the same structure as an in-person one, just carried over video: shared slides for business context and architecture vision, breakout rooms mapped one-to-one with physical breakout tables, a digital program board every team can edit at once, and a synchronous confidence vote where everyone raises fingers on camera at the same time, not an async form filled out over the following two days. What doesn't translate well is trying to compress the event into fewer hours because it's remote. Teams still need the full breakout time to actually estimate and draft a plan; cutting that time to save meeting fatigue just pushes the real planning work into hallway conversations that never happen.

Time zones are the other real constraint. ARTs spanning more than a few hours of offset usually either shift the agenda to a window everyone can attend live, or split into a "core hours" model where breakouts run async within a team's own zone and only the shared context and confidence vote happen fully synchronously. Either works. What doesn't work is quietly excluding a time zone from the parts of the agenda that actually require the whole ART together.

Good PI Planning vs. Planning Theater

Some PI Planning events genuinely coordinate an ART. Others just perform the ceremony while nothing real changes. The difference usually shows up in a handful of specific symptoms.

If your PI Planning event consistently produces a five-finger vote, a program board nobody references between events, and PI objectives so vague they could apply to any team in any quarter, you're not running SAFe's planning event. You're running a two-day status meeting with better branding.

The Day After: What a Team Does Next

The morning after PI Planning ends, three things need to happen fast, before the energy from the event evaporates into the first regular iteration.

First, the artifacts get published somewhere everyone can find them: final PI objectives, the program board (digitized if it was built on a physical wall), and the ROAMed risk list with named owners. If these live only in someone's photos from day two, they're already starting to decay.

Second, teams translate their committed PI objectives into the first iteration's actual backlog. PI Planning produces a PI-level plan, not a sprint-ready one; the first sprint planning session of the new PI is where that gets broken down into stories a team can start immediately.

Third, the RTE schedules the recurring cadence that keeps the plan alive: ART sync (Scrum of Scrums plus a Product Owner sync), a regular review of the program risk list, and a checkpoint on any dependency flagged during planning that hasn't been resolved yet. A PI Planning event that isn't followed by a working cadence for the next 8 to 12 weeks was, functionally, theater with extra steps. The plan only stays real if someone keeps checking it against reality.

Getting PI Planning right isn't about running a longer agenda or adding more roles to the room. It's about treating the artifacts as real commitments, the confidence vote as an actual signal, and the weeks before and after the event as part of the process, not padding around it. Teams that do that turn PI Planning into the coordination mechanism it's meant to be. Teams that don't just get a very expensive two-day meeting, four times a year.