PI Planning

“PI Planning is not a meeting. It’s the single highest-leverage event in scaled Agile delivery — two days where every team either gets aligned or spends the next twelve weeks paying for the gaps.”

There’s a version of PI Planning that most enterprise teams recognize: two days in a large conference room, sticky notes on walls, teams filling out program boards, and an executive opening keynote that runs 45 minutes too long. Everyone leaves exhausted, the boards look impressive, and by week three of the first iteration, half the dependencies have blown up and nobody can remember exactly what was committed to.

Then there’s the version that actually works.

The difference between those two versions is not the framework, the tools, or the size of the room. It’s whether the people in that room — BAs, POs, QA leads, architects, developers, and business stakeholders — understand precisely what they’re responsible for during those two days, and what the output of those two days needs to look like for the next Program Increment to deliver real business value.

This post covers PI Planning completely: what it is, why it exists, the two-day agenda structure, every role’s specific responsibilities, real examples from healthcare, banking, retail, telecom, construction, technology, finance, and transportation, and the most common failure patterns that turn a PI Planning event into a very expensive alignment theater.

What PI Planning Actually Is – And What It’s Not

Program Increment Planning – PI Planning – is a cadence-based, face-to-face event that serves as the heartbeat of the Scaled Agile Framework (SAFe). It brings together all the teams in an Agile Release Train (ART) — typically 5 to 12 teams, 50 to 125 people — for a structured two-day event that aligns them around a shared mission, establishes a common iteration plan for the next 10 to 12 weeks, and surfaces cross-team dependencies and risks before development begins.

SAFe defines a Program Increment as a timebox of 8 to 12 weeks in which an Agile Release Train delivers incremental value in the form of working, tested software and systems. PI Planning is what sets that increment in motion. It’s the event where business context meets team capacity, where feature priorities meet technical constraints, and where the backlog stops being a list and starts being a commitment.

What PI Planning is not:

• It’s not sprint planning at scale. Sprint planning fills a two-week backlog. PI Planning sets the direction for twelve weeks across every team in the train.
• It’s not a project kickoff. Kickoffs announce decisions already made. PI Planning is where the decisions get made collaboratively, with input from every team.
• It’s not a BA handoff event. The BA doesn’t bring finished requirements to PI Planning and hand them over. The BA brings drafted features and works through them in real time with every team affected.
• It’s not optional for QA. QA participation in PI Planning is not a courtesy. It’s where testing capacity is planned, testing dependencies are identified, and the quality strategy for the entire PI is established.

PI Planning connects directly to every phase of the Software Development Life Cycle. It’s the macro-planning event that determines what enters each sprint, what the testing lifecycle needs to support, and what the business expects to see at the System Demo at the end of each iteration.

The People in the Room: Every ART Role and What They Own

PI Planning only produces value proportional to the clarity of role accountability in the room. When everyone knows their lane, the two days produce a coordinated plan with owned commitments. When roles are blurred, the two days produce a document that nobody truly owns.

For deeper context on the core delivery roles, see the full guides on what a Business Analyst does, the Product Owner role, and QA in modern delivery teams.

The Two-Day PI Planning Agenda: Hour by Hour

The SAFe PI Planning agenda is prescriptive for good reason. Each block has a purpose, and when any block is cut short — particularly the team breakouts and the management review — the quality of the output degrades predictably. Here’s the standard two-day structure, with role ownership called out for every session.

Day 1: Context, Vision, and Team Planning

Day 2: Refinement, Risk, and Final Commitment

The most consistently underexecuted block is Team Breakout #1. This is where the real work happens — six hours of cross-functional collaboration where the BA’s ability to answer requirement questions in real time, QA’s ability to estimate testing capacity accurately, and the developer’s ability to flag technical constraints all directly determine whether the draft plan is credible or aspirational. Teams that use this block well leave Day 1 with a realistic plan. Teams that use it poorly spend all of Day 2 trying to reconcile a plan nobody actually believes in.

PI Objectives: The Output That Matters Most

PI objectives are the primary output of PI Planning. Each team produces a set of 3 to 5 business-value-oriented objectives that describe what they intend to accomplish in the PI, along with a business value score (1-10) assigned by the business and a stretch objective for features that may or may not be achievable depending on how the PI unfolds.

The distinction between a good PI objective and a bad one is the same as the distinction between a good acceptance criterion and a vague requirement: specificity and measurability. A PI objective that says “Improve the claims processing workflow” is not a PI objective. It’s a direction. A PI objective that says “Deliver automated prior authorization routing for all commercial plan types, reducing average auth processing time from 4.2 days to under 24 hours for 90% of requests” is a PI objective. It has a measurable outcome, a defined scope, and a clear business value statement.

The BA’s role in PI objective quality is critical and often underutilized. Strong PI objectives don’t write themselves — they emerge from a BA who understands the business well enough to translate a feature into a measurable outcome statement, and who works with the PO during the team breakout to ensure the objective reflects what the business actually needs to see by PI end.

PI Planning Across 8 Industries: What Changes, What Doesn’t

PI Planning’s structure is consistent across industries. What changes is the content that fills that structure — the regulatory requirements that shape features, the integration constraints that create dependencies, and the business stakeholders who define what “done” looks like. Here’s how PI Planning manifests across eight industries where the stakes are concrete and the planning gaps are expensive.

The pattern across all eight industries: regulatory and compliance-driven features consistently arrive at PI Planning underspecified, and they consistently create the most cross-team dependencies and the most risk register entries. In every industry, the BA who walks into PI Planning with pre-drafted acceptance criteria for regulatory features — not just feature names — compresses the team breakout time significantly and produces more credible PI objectives.

The Program Board: How Dependencies and Milestones Get Mapped

The program board is the physical or digital artifact that makes PI Planning’s cross-team commitments visible to everyone. It’s a grid with teams on one axis and iterations on the other, with features, stories, dependencies (shown as string or arrows), and milestones posted for the entire ART to see.

Understanding the program board is essential for every role — not just the RTE who maintains it. Here’s how each element maps to team-level work.

The program board is most powerful when dependency arrows are treated as negotiated agreements, not aspirational connections. When Team A draws an arrow to Team B’s feature in Iteration 2, that arrow needs to be acknowledged and confirmed by Team B’s PO and dev lead in the room. An unacknowledged dependency on the program board is a future sprint blocker waiting to happen.

The ROAM Risk Workshop: Where Risks Get Owned, Not Just Listed

The ROAM Risk Workshop is one of the most structurally important sessions in PI Planning and one of the most frequently shortchanged. ROAM stands for Resolved, Owned, Accepted, and Mitigated. Every risk surfaced during PI Planning gets classified into one of these four categories. The ones that don’t get classified become the risks that blow up in Iteration 3.

The BA’s role in the Risk Workshop is specifically around requirement risks — features that are too vague to build confidently, dependencies on business stakeholder decisions that haven’t been made, and regulatory requirements that haven’t been fully analyzed. Every unresolved requirement question that enters the PI without a risk classification is a defect that hasn’t been filed yet. It will surface — the only question is which iteration it disrupts.

Role Activity Matrix: Who Does What Across the PI Planning Event

This matrix connects directly to both the Scrum framework that each team runs within the ART and the broader SDLC that PI Planning is designed to execute at scale.

The 9 Most Expensive PI Planning Failure Patterns

Pre-PI Preparation: The Work That Determines PI Planning Quality

PI Planning quality is almost entirely determined by what happens in the two to three weeks before the event. Teams that show up prepared — with refined backlogs, feature-level acceptance criteria, and a clear understanding of their capacity — consistently produce more credible plans than teams that treat PI Planning as their first opportunity to read the features.

PI Planning and the Testing Lifecycle: The Connection Most Teams Miss

PI Planning is where the Software Testing Life Cycle gets resourced and sequenced for the entire Program Increment. Every feature that enters a PI carries testing implications — integration testing dependencies between teams, performance testing requirements that need environment access, security testing that needs to be scheduled against specific milestones, and BAT that needs BA availability planned across the PI calendar.

When QA participates in PI Planning correctly, the output includes not just iteration-level story commitments but a PI-level test strategy that answers five questions:

• What features require integration testing between teams? Those get dependency arrows and specific iteration targets on the program board.
• What features require performance or load testing? Those need environment reservations and iteration scheduling that accounts for performance test run time.
• What features carry compliance or security testing requirements? Those often need specialized tools, environments, or third-party coordination that takes longer than a sprint to arrange.
• What is the automation backlog for this PI? New features generate new automation candidates — those need to be scoped and estimated alongside the feature work they support.
• What is the BAT schedule across the PI? BA availability for BAT needs to be planned at the PI level, not discovered at the end of each sprint when BAT is supposed to happen.

For a complete breakdown of how testing types map to the PI execution model, see the guides on types of software testing and the full STLC breakdown.

Two Days. Twelve Weeks. Make It Count.

PI Planning is the moment where alignment either gets built or gets assumed. Teams that walk out of those two days with clear PI objectives, acknowledged dependencies, classified risks, and a testing strategy that accounts for the entire PI deliver better — not because they’re smarter or faster, but because they made the hard conversations happen in a room together instead of in a Slack thread three weeks into the PI when the damage is already done.

The BA who walks in with completed acceptance criteria makes team breakouts faster and more confident. The QA lead who walks in with a testing capacity plan makes iteration commitments more credible. The PO who walks in with a prioritized, sized backlog makes the planning conversation about value rather than scope. The developer who walks in having read the features makes the estimation more accurate and the risk identification more complete.

PI Planning doesn’t fix a broken backlog, a BA who isn’t embedded in delivery, or a QA function that’s been excluded from requirements. Those problems follow the teams into the PI and compound with every iteration. But for teams that have done the preparation work, PI Planning is the highest-leverage two days on the delivery calendar — the event where twelve weeks of complexity gets organized into something executable, visible, and owned.

For the complete role and framework context used throughout this post, explore the guides on Business Analysis, Product Ownership, Quality Assurance, Scrum, types of software testing, the Software Testing Life Cycle, and the full SDLC guide at TechFitFlow.