PI Planning Mechanics

What PI Planning Is

PI Planning is a two-day event that brings an entire Agile Release Train — typically 50–125 people — into one room (or virtual space) to plan the next Program Increment.¹ It's SAFe's most distinctive ceremony and, when done well, its strongest contribution to scaled coordination.

The event is unusual in modern agile practice. The agile movement spent years arguing against big-room planning. PI Planning brings it back deliberately, on the premise that some work genuinely requires many people to align in a single moment, and that doing it once every 8–12 weeks is more honest than doing it implicitly through endless coordination meetings.

The Standard Two-Day Agenda

Day 1

• Business context (1 hour): senior executives present the business situation, strategic themes, and what's expected of the train this PI.
• Product/Solution vision (1 hour): Product Management presents the planned features and priorities.
• Architecture vision (30 min): System Architect presents technical guidance and enablers.
• Team breakouts (4 hours): each team plans the sprints of the PI, working through stories, identifying dependencies, and posting them on the program board.
• Draft plan review (1.5 hours): each team presents draft plans; risks and dependencies surface.
• Management review and problem-solving (1 hour): leadership reviews issues and decides what changes for day 2.

Day 2

• Planning adjustments (15 min): any changes from day 1 review communicated.
• Team breakouts (3 hours): teams finalize plans, adjust based on overnight thinking.
• Final plan review (2 hours): each team presents the final plan, PI Objectives, and Confidence Vote.
• Program risks review (30 min): remaining risks surfaced and addressed.
• Confidence Vote on the program plan (15 min): the entire ART votes on confidence in the plan.
• Plan rework (if needed) and retrospective (1 hour): if confidence is low, rework; close with a retrospective of the planning event itself.

The Program Board

The visible artifact of PI Planning is the Program Board: a large wall display with rows for each team, columns for each sprint, and cards showing features and stories. Dependencies between teams are shown as strings connecting cards. The board is the planning artifact and the coordination tool — visible all PI long.

In remote PI Planning, the program board moves to tools like Miro, Mural, or Jira Plans. The remote version is functional but loses some of the kinetic energy of physical strings stretched across a wall.

The Confidence Vote

At the end of day 2, every participant in the ART votes on confidence in the program plan, on a 1–5 scale (fist of five). If the average is 3 or above, the plan is accepted. Below 3, plans need rework. Below 2, significant rework or replanning is required.

The vote is the framework's most distinctive mechanism. It treats the plan as something the team commits to, not something handed down. When done honestly, it surfaces problems before they're locked in.

What Makes PI Planning Work

• Real authority in the room. Business owners must be able to make decisions during the event. If they have to escalate to absent executives, the event becomes performance.
• Pre-PI Planning. The features being planned should be refined enough that teams can work them. PI Planning is not for refining; it's for committing.
• Cross-team conversation, not parallel work. The event's value is the unscheduled side conversations that resolve dependencies. If teams hide in breakout rooms, the value evaporates.
• Honest confidence vote. If everyone always votes 5, the vote is theatre. Coaches must protect honesty.
• Time-box discipline. 30 minutes for vision, 30 minutes for architecture, 4 hours for breakouts. Without discipline, the event sprawls.

What Makes It Fail

• Big-room status reporting. The event becomes a parade of demos and presentations with no genuine planning.
• Pre-baked plans. Leadership has decided the outcome before the event; the event ratifies it. Teams notice and disengage.
• Confidence-vote inflation. Everyone votes 5 regardless of actual confidence. The signal dies.
• No follow-through. Plans are made; nothing tracks against them; the next PI ignores what was committed.
• Refinement during planning. Features arrive too rough; the event becomes refinement instead of planning. Bring proper refinement upstream.

Remote PI Planning

The 2020 pandemic forced remote PI Planning at massive scale. The format adapts but requires changes:

• Shorter days (4–6 hours, not 8).
• More frequent breaks (every 60–90 minutes).
• Smaller breakout sizes.
• Heavier reliance on async-prepared materials.
• Tools (Miro, Mural, Zoom) that explicitly support the planning artifacts.

Remote PI Planning works; it just costs more in facilitation and coordination than the in-person version.

Coaching Tips

Invest heavily in pre-PI refinement.

If features arrive rough, planning collapses into refinement. The two weeks before PI Planning matter as much as the event.

Protect side conversations.

The corridor talk between breakouts is where dependencies get resolved. Design the event to enable it.

Demand honest Confidence Votes.

If everyone votes 5, ask for thumbs that aren't fives. The vote must be genuine or it isn't a vote.

Watch for pre-baked plans.

If leadership announces the answer before breakouts, the event is theatre. Push back.

Time-box ruthlessly.

The agenda overruns kill PI Planning. Each segment has its time-box; enforce it.

Track PI outcomes vs. plans.

If commits routinely miss without learning, the event becomes pageantry. Track and retro on the gap.

Summary

PI Planning is SAFe's strongest mechanic when run well and its most theatrical when run badly. The two-day big-room event compresses what would otherwise be weeks of coordination meetings into a single concentrated moment. The discipline of bringing everyone together, surfacing dependencies, and voting on the plan honestly is what produces the real alignment value. Without that discipline — and the upstream refinement work that makes it possible — PI Planning becomes the largest, longest waste of organizational time available.

Back to Scaling Agile