PI Planning

Definition

PI Planning — Program Increment Planning — is the two-day, cadence-based event at the heart of the Scaled Agile Framework (SAFe). Every 8–12 weeks, all teams on an Agile Release Train come together in the same room (physical or virtual) to plan the next Program Increment. The output is a set of committed objectives, a dependency map, a risk log, and a confidence vote from every team.

The Two-Day Rhythm

• Day 1 morning: business context, product vision, architecture vision, top-10 features.
• Day 1 afternoon: team breakouts — draft plans, identify dependencies and risks.
• Day 1 end-of-day: draft plan review, management review and problem-solving.
• Day 2 morning: planning adjustments, refine team objectives.
• Day 2 afternoon: final plan review, program risks (ROAM'd — Resolved, Owned, Accepted, Mitigated), confidence vote, planning retrospective.

Why It Matters

Organisations running 50+ engineers across 6+ teams cannot rely on the informal coordination that works for a single Scrum team. PI Planning replaces the slow, asynchronous dependency negotiation that otherwise absorbs a quarter of engineering capacity. It also gives leadership a single, honest checkpoint: after two intense days, they either have a plan the teams have signed up to, or they know they don't — both are useful.

Real-World Example

A digital-banking programme running eight teams across three countries moved from quarterly release planning by roadmap slide to full PI Planning. The first event exposed 34 cross-team dependencies that the roadmap had assumed away. The confidence vote came in at 2.8/5 — teams voted honestly and management resisted the temptation to reframe it. Fourteen features were dropped or deferred; the remaining plan was delivered at 91% completion over the next 10 weeks. The prior increment on the same portfolio had been "committed" at 100% and landed at 54%. PI Planning did not create the dependencies; it simply forced them onto the table where they could be resolved.

Practical Lessons Learned

• Same room beats every alternative. Even distributed teams should co-locate for the event — the emergent conversations at the break are where dependencies actually get resolved.
• Prepare the backlog ruthlessly. Features that arrive at PI Planning half-defined destroy the two days.
• The confidence vote is data, not theatre. A 2.5 vote means the plan is wrong, not that the teams are pessimistic.
• Program risks get ROAM'd. "We'll figure it out" is not one of the four categories for a reason.
• The plan is committed, not signed in blood. Reality changes; the plan changes; the point is that everyone agrees on the plan today.

Common Mistakes

• Treating PI Planning as a scaled sprint planning — it is a coordination event across teams, not a task-level plan.
• Product management arriving with a fixed roadmap and no room to change it.
• Skipping the confidence vote or averaging it upward to management-friendly numbers.
• Insufficient pre-planning — the feature backlog needs to be refined weeks in advance.
• Missing the retrospective — the event improves only if the previous one is critiqued honestly.
• Running PI Planning without an Agile Release Train structure — the event depends on stable teams-of-teams.
• Trying to squeeze a 200-person event into a Zoom call without breakouts, physical boards or facilitated dependency management.

Expert Tips

• The program board is the artefact that matters. Every feature on every team's swim lane, every dependency drawn in red string. Photograph it before people leave the room.
• Timebox ferociously. Every session has a hard stop; discussions that need more time get carried into a scheduled follow-up, not extended in the moment.
• Involve architecture and shared services teams as first-class participants, not observers. They own more dependencies than anyone in the room.
• Publish objectives in business language. "Onboard 500k new customers with under 6 minutes average time-to-first-transaction" is an objective; "complete API integration" is a task.
• Retrospect the event immediately. Two hours on Day 2 afternoon, whole train, honest feedback. Next PI Planning improves as a result.

Key Takeaways

• PI Planning is the coordination event that makes multi-team agile at scale actually work.
• Two days, same room, all teams, honest confidence vote.
• The program board — features by team, dependencies drawn — is the durable artefact.
• Program risks are ROAM'd; there is no fifth category.
• Preparation determines outcome; unrefined backlogs destroy the event.

Related Concepts

Interlocks with Release Train, Iteration Planning, Story Slicing, Backlog Refinement, and OKRs. Facilitation guides and program-board templates at PMMilestone.org.