SAFe PI Planning: Complete Guide for Scrum Masters and RTEs in 2025

PI Planning is the heartbeat of SAFe delivery. Every 8–12 weeks, every team in the Agile Release Train (ART) gathers — physically or virtually — for a 2-day event that aligns strategy, plans sprints, identifies dependencies, and commits to PI objectives. Done well, it is one of the most powerful alignment tools in enterprise Agile. Done poorly, it is an expensive theatre exercise that produces plans nobody follows. This guide covers how to do it well.

What Is PI Planning?

PI Planning (Programme Increment Planning) is a SAFe event where all teams in an ART meet to plan the next Programme Increment — typically 5 sprints (10 weeks). The output is a set of PI Objectives for each team, a programme board showing features, dependencies, and milestones, and a Risk Register populated via ROAM.

PI Planning is covered in CREA-SM Module 4 (Scaling Agile) because understanding it is essential for any Scrum Master working in a SAFe environment — which represents approximately 40% of enterprise Agile organisations.

The 2-Day PI Planning Agenda

Day 1

• Business Context (2 hours): Business Owner or CEO presents the current state, strategic themes, and top 10 features for the PI. This sets the "why" for everything that follows.
• Product/Solution Vision (1 hour): Product Management presents the vision, roadmap, and the features teams will work on. Architecture presents the Architectural Runway.
• Team Breakouts — Iteration 1 (4 hours): Teams plan their first iteration, identify capacity, discuss features with Product Owners, and begin populating the Programme Board with dependencies.
• Draft Plan Review (1 hour): Each team presents their draft plan. Red flags are surfaced. Business Owners provide initial input.

Day 2

• Team Breakouts — Remaining Iterations (4 hours): Teams complete iteration planning for all 5 sprints of the PI. Dependencies are negotiated between teams. Programme Board is updated.
• Final Plan Review (2 hours): Each team presents their final plan and PI Objectives. Business Owners assign business value scores (1–10) to each objective.
• ROAM Risks (1 hour): All risks identified during planning are classified using the ROAM framework.
• Confidence Vote: Each team votes on their confidence in delivering the PI plan (fist of five). Low confidence triggers immediate discussion.

The ROAM Risk Framework

Every risk identified during PI Planning is classified into one of four categories:

• R — Resolved: The risk no longer exists. Removed from the register.
• O — Owned: The risk cannot be resolved now but is accepted and owned by a named individual who will manage it.
• A — Accepted: The risk is known, cannot be mitigated, and the team accepts the potential consequence.
• M — Mitigated: A specific mitigation action has been agreed and added to a team's backlog.

ROAM is not a risk assessment framework — it is a risk disposition framework. The goal is to ensure every risk has a clear status, not to eliminate all risk.

Scrum Master Responsibilities in PI Planning

The Scrum Master's role during PI Planning is often unclear. Specific responsibilities:

• Pre-event: ensure the team backlog is refined to at least 2 sprints depth before PI Planning. Arrive with estimates, not blank items.
• Day 1 breakout: facilitate the team's capacity calculation. Challenge unrealistic commitments. Protect the team from over-committing on Day 1.
• Programme Board: own your team's sticky notes on the programme board. Ensure every dependency has a named owner on both sides.
• Day 2 breakout: chase outstanding dependency confirmations from other teams. Do not leave PI Planning with unconfirmed dependencies.
• Confidence vote: if your team votes below 3, you must articulate the specific risk. "We're not sure" is not sufficient.

Virtual PI Planning: What Changes

Post-2020, many ARTs run hybrid or fully virtual PI Planning. The structure is identical; the tooling changes. Miro or MURAL replaces the physical programme board. Breakout rooms replace physical team spaces. The biggest facilitation challenge is dependency negotiation — it is harder to catch a colleague in a breakout room virtually than physically. Build explicit dependency discussion time into the Day 2 agenda.