If SAFe has a heartbeat, PI Planning is it. Every 8–12 weeks, an entire Agile Release Train — typically 50 to 125 people across 5–12 teams — gathers for two days to plan the next Program Increment together. Out of those two days comes a concrete plan: who's building what, in which iteration, with which dependencies mapped and which risks owned. The event is covered in depth in the Leading SAFe course and is central to the Scrum Master and RTE roles.

This guide is PI Planning explained from the perspective of someone who has facilitated it for dozens of ARTs — the agenda, who does what, the four outputs that actually matter, how remote and hybrid events differ, the common failure modes, and how to tell a great PI Planning event from one that's going through the motions.

What is PI Planning?

PI Planning is a cadence-based, face-to-face (or face-to-screen) event where every team on an Agile Release Train plans the next Program Increment together. A Program Increment (PI) is a fixed timebox — usually 8–12 weeks, made up of 4–6 iterations including a final Innovation & Planning (IP) iteration.

The core idea: teams plan their own work, but they plan it together in the same room. That's what separates it from command-and- control planning where someone hands down a plan from above.

“The thing that makes PI Planning work isn't the plan — it's the fact that 100 people built it in the same room.”

Why it matters

• Alignment without control. Business context and architecture vision are communicated to everyone at the same time. Teams plan within that context.
• Dependencies become visible. Eight teams all working on the same system have cross-team dependencies — PI Planning forces those into the open on the program board where they can be negotiated.
• Risk management in public. Risks get ROAMed (Resolved, Owned, Accepted, Mitigated) in front of everyone — no quiet hope that it works out.
• Team commitment is real. Teams set their own PI objectives and take a confidence vote. Plans that come out of this event carry more weight than plans built by a project manager alone.

Scrum Masters play a critical facilitation role during PI Planning. Full role coverage is in the SAFe Scrum Master course.

The 2-day agenda

Every well-run PI Planning follows the same basic structure. The timing varies by time zone and ART size, but the flow is the flow.

Day 1 morning: Set the context

• Business context — a senior executive opens with the current state of the business and what success looks like
• Product / solution vision — Product Management walks through top features, changes, and priorities
• Architecture vision & dev practices — the System Architect covers architectural enablers and tech approach
• Planning context — the Release Train Engineer sets expectations, process, and logistics

Day 1 afternoon: First team breakouts

Teams split off and build a draft plan — features pulled from the program backlog, broken into stories, sized, and placed in iterations. Scrum Masters facilitate, Product Owners prioritize, dependencies go up on the program board. The ART scrum of scrums meets at least once to surface cross-team issues.

Day 1 end: Draft plan review + management review

Each team presents their draft plan, including risks and dependencies. After teams leave, leadership meets to make adjustments — scope changes, capacity shifts, descoped objectives — so teams come back Day 2 with the tradeoffs already made.

Day 2 morning: Planning adjustments + second breakouts

The RTE announces any changes. Teams incorporate them, finalize their PI objectives, and refine the program board. This is where rough plans become committed plans.

Day 2 afternoon: Final plan review + confidence vote

Each team presents its finalized PI objectives, business value scores from Business Owners, and program-level risks. Program risks are ROAMed live. Then every individual votes 1–5 fingers on confidence in the plan. Average under 3 triggers rework. Average 3 or above — plan is committed.

The event closes with a short planning retrospective and a "moving forward" section — who's doing what starting Monday.

Who's in the room

• Release Train Engineer (RTE) — the senior facilitator, owns the event
• Business Owners — executives accountable for business value; score objectives
• Product Management — brings the prioritized program backlog, owns the vision
• System Architect / Engineering — architectural runway and technical guidance
• Product Owners — one per team, prioritize team work during breakouts
• Scrum Masters — facilitate team-level planning, help surface dependencies and risks
• Team members — the people who will actually do the work, sizing their own stories
• Shared Services & SMEs — security, UX, data, compliance representatives available to consult

The 4 outputs that matter

Many teams leave PI Planning with a thick document that no one ever reads. The four things that actually matter:

1. PI Objectives — a concise list per team, plus program-level objectives. Each has a business value score from Business Owners (1–10). Stretch objectives are called out separately.
2. The Program Board — a visual (physical sticky wall or Miro / Mural board) showing features by iteration, team, and dependencies mapped with strings or lines. The single most valuable artifact.
3. ROAMed Program Risks — every significant program risk categorized as Resolved, Owned, Accepted, or Mitigated, with an owner where needed.
4. Confidence Vote — a real-time read of whether the plan is achievable. Average ≥ 3 means the ART has committed.

Remote and hybrid PI Planning

Since 2020, most ARTs run PI Planning fully remote or hybrid. It works when three things are true:

• A single digital program board (Miro, Mural, or similar) that every team uses — one source of truth for dependencies
• Video on in all team breakouts — facilitation is harder without faces
• Breaks every 90 minutes — Zoom fatigue kills plan quality after hour four

Hybrid events (some rooms in person, some teams remote) are the hardest to run well. If you can't commit to either fully remote or fully in-person, consider scheduling the event over three half-days rather than two full days.

Common failure modes

Common questions

How often does PI Planning happen?

Once per Program Increment — usually every 8–12 weeks, matching the PI cadence.

How long is PI Planning?

Two days. Some remote events split it into three half-days, but the total facilitated time is still roughly 16 hours.

Who facilitates PI Planning?

The Release Train Engineer owns the event. Scrum Masters facilitate team breakouts. The RTE role is covered in depth in the SAFe Release Train Engineer course.

What's the difference between PI Planning and Sprint Planning?

Sprint Planning is for one team, one sprint (1–2 weeks). PI Planning is for an entire ART (5–12 teams), one PI (8–12 weeks). Teams still do Sprint Planning at the start of each iteration — PI Planning sets the broader context for all of them.

Can you do PI Planning without SAFe?

You can run a similar event — many orgs do — but calling it PI Planning implies the SAFe structure (ART, PI cadence, program backlog, Business Owners). Without those pieces, you're doing something else. Before you decide on a framework, compare the SSM vs CSM certification paths to see which fits your organization.

What does a successful PI Planning look like?

Finalized PI objectives that every team believes in, a program board with dependencies visibly mapped, risks ROAMed with owners, a confidence vote averaging 3 or higher, and a planning retrospective that produced one or two concrete improvements. If any of those are missing, the event didn't land.

How do remote PI Planning events differ?

The agenda is identical. The logistics are harder: one shared digital program board, stricter time discipline, video on in breakouts, anonymous polling for confidence votes. Well-run remote PI Planning is as effective as in-person — but it requires more preparation, not less.

Is PI Planning covered in SSM training?

Yes. A meaningful portion of SAFe Scrum Master exam questions involve PI Planning facilitation. The RTE and Leading SAFe certifications cover it in more depth.

Where to go from here

If you're planning to facilitate PI Planning, the Release Train Engineer certification is the right path. If you're planning to lead your organization toward adopting SAFe, start with Leading SAFe.

Related reading: SAFe LPM vs POPM · Is SAFe certification worth it