PI Planning is SAFe's most distinctive — and most debated — event. Imagine getting 50 to 125 people in a room (or video conference) for two full days to plan the next three months of work. To outsiders, it sounds expensive and bureaucratic. To practitioners, it's often the most valuable two days of the quarter.
This lesson gives you a front-row seat without having to survive your first one unprepared.
Learning Objectives
- Describe the structure and agenda of a PI Planning event
- Explain what a Program Board is and how it makes cross-team dependencies visible
- Define ROAM and how it manages risks identified during PI Planning
- Prepare effectively for PI Planning as a QA engineer or BA
The PI Planning Agenda
A standard PI Planning runs over two days. The structure is consistent across most SAFe implementations:
Day 1:
- Business Context: Leadership presents the vision, strategic themes, and top features for the PI
- Product/Solution Vision: Product Managers walk through the Program Backlog's top priorities
- Architecture Vision: System Architects present the technical direction for the PI
- Team Breakouts (Round 1): Each team plans their first 2 sprints, identifies risks and dependencies
- Draft Plan Review: Teams present their draft plans to the full group — a rapid fire review
Day 2:
- Team Breakouts (Round 2): Teams refine their plans based on Day 1 feedback and cross-team conversations
- Final Plan Review: Each team presents their final commitments, PI objectives, and known risks
- ROAM Risks: The group collectively ROAMs the risks
- Confidence Vote: The entire ART votes on confidence in the plan
The Program Board
The Program Board is the visual centrepiece of PI Planning. It's a large grid where:
- Rows represent teams
- Columns represent sprints in the PI
- Cards on the board represent features committed to each sprint
- Strings (literal red strings or digital connections) connect dependencies between teams
The Program Board makes cross-team dependencies visible in a way that no backlog tool does. When Team A's "Deploy Payment API" in Sprint 2 is connected by a string to Team B's "Integrate Payment Flow" in Sprint 3, everyone can see:
- Team B cannot start Sprint 3's work until Team A finishes Sprint 2's work
- If Team A is at risk of slipping, Team B needs to know immediately
- This dependency should be discussed, managed, and tracked through the PI
Risk flags on the Program Board:
- 🔴 Red: known risk, not yet mitigated
- 🟡 Yellow: risk being tracked
- 🟢 Green: dependency acknowledged and managed
ROAM — Risk Management at PI Scale
During the Final Plan Review, every identified risk is ROAMed — a structured risk disposition process:
| ROAM status | What it means | Who acts |
|---|---|---|
| Resolved | Risk no longer exists — teams made a decision that eliminates it | The involved teams |
| Owned | A specific person takes ownership and a mitigation plan | Named individual |
| Accepted | Risk is real, can't be eliminated, but we accept it and proceed | Product Manager / ART |
| Mitigated | An action has been taken to reduce the risk's probability or impact | Named team or person |
After ROAMing, every risk has a disposition. "We'll worry about it later" is not a valid ROAM response — which is part of what makes the process valuable.
The Confidence Vote
At the end of Day 2, the RTE asks the entire ART: "How confident are you in this plan?" Everyone simultaneously holds up 1–5 fingers:
- 5: Full confidence — we can definitely deliver this
- 4: Good confidence — likely to deliver
- 3: Some concerns — delivery is uncertain
- 2: Low confidence — significant concerns
- 1: No confidence — we should replan
If the average is below 3, PI Planning doesn't end — the ART replans until confidence improves. This is not a rubber stamp exercise. It's a forcing function for honest commitment.
As a QA engineer or BA, your vote matters. If you're not confident in the plan's testability, quality gates, or requirements clarity, you should vote low and explain why. Staying silent and then watching the PI fail is not better.
How to Prepare for PI Planning as a QA / BA
Before PI Planning:
- Review the top features on the Program Backlog — understand what's coming
- Identify which features touch your current regression test suite (and which tests might need updating)
- Note any shared test environments, test data, or infrastructure that might be needed by multiple teams
- Prepare questions about acceptance criteria for large/ambiguous features
During PI Planning:
- Participate actively in team breakout — you have important information about testability and requirement clarity
- Flag features with ambiguous acceptance criteria during the vision presentation
- Identify testing dependencies that should appear on the Program Board
- During the confidence vote, be honest about your level of confidence in the quality plan
After PI Planning:
- Track the Program Board dependencies that affect your team
- Ensure the team's PI objectives include explicit quality outcomes (not just feature delivery)
- Schedule early integration testing dates — don't leave all integration testing to Sprint 4
Pro Tip: The most valuable thing a QA can do at PI Planning is ask "how will we know this feature is done?" for every major feature in the backlog. If the answer is vague or there's no acceptance criteria, that's a risk to ROAM — not something to ignore until Sprint 3.
Summary
- PI Planning is a two-day event where the entire ART plans the next 8–12 weeks together
- The Program Board visualises cross-team feature commitments and dependency strings
- ROAM turns identified risks into owned, actionable dispositions
- The Confidence Vote is a genuine forcing function — a sub-3 vote means replan, not proceed
- QA and BA contributions during PI Planning significantly improve plan quality and reduce late-sprint surprises