Your 101 on Program Increment (PI) Planning (SAFe tutorial)

If you’re not doing Program Increment (PI) Planning, you are not doing SAFe®. At least, that’s what the official narrative of The Scaled Agile Framework says flat-out. In reality, teams usually fall into two camps: they either deem PI Planning to be a transformational alignment ceremony, or a two-day calendar hostage situation.

Well, the truth lies somewhere in between, and as a planning practice, PI Planning tends to mirror the entire organization running it. Anyway, here’s our essential guide to running the most intense 2 days in the Agile calendar (aka PI Planning), without losing your mind (or your roadmap).

TL;DR:

• PI Planning is a 2-day event where multiple agile teams turn the uncertainty of the next quarter into a shared, committed plan.
• The quality of PI Planning depends on the setup around it. If priorities are unclear, ownership is weak, or the plan disappears after the event, the two days were a waste of time. If the plan is kept live and visible, it becomes a real management tool
• Beyond the agenda itself, PI Planning involves several practices designed to test whether the organization can think and act as one system. To get real value from it, the plan needs to stay simple, owned, and grounded in actual capacity.

What is Program Increment (PI) Planning?

Program Increment (PI) Planning is the quarterly event that brings multiple agile teams, stakeholders, and leadership into one room. Over two days, they align on what to build in the next 8–12 weeks and commit to a shared plan. That 8–12 week window is the Program Increment itself: a fixed timebox holding 4–6 iterations plus one final IP Iteration.

PI can go by different names in different companies. You might hear 90-day planning, quarterly planning, big room planning, or simply ART sync, but the intent of this type of event stays the same: to get every team aligned around a shared plan before the quarter starts. SAFe documentation uses “Planning Interval” and “Program Increment” interchangeably since SAFe 6.0. In practice, most teams still say “Program Increment,” and that's what we'll use throughout this guide.

The SAFe vocabulary you'll need

SAFe is a fairly layered system with lots of roles, rules, and moving parts, so it can feel a bit overwhelming at first. If you're just getting started, it might benefit from getting into the context first. That's why we've put together a quick-reference glossary of the key terms you’ll run into when reading about or running PI Planning:

Term	What it means in practice
Agile Release Train (ART)	The long-lived team of multiple teams (typically 50–125 people across 5–12 Agile teams) that plans and delivers together.
Release Train Engineer (RTE)	The servant leader who owns and facilitates PI Planning.
PI Objectives	Short statements of what every team commits to deliver during the PI, scored from 1 to 10 depending on business value.
Program Board	The entire plan represented as large board mapping features, cross-team dependencies, and milestones.
Business Owners	The executives and senior stakeholders accountable for ROI and business outcomes. They score PI Objectives and participate in trade-off decisions.
ROAM (Resolved, Owned, Accepted, Mitigated)	The risk classification technique used at the end of Day 2.
Confidence Vote	The closing ritual: every participant votes 1–5 fingers on their confidence in the plan.
IP Iteration	The last iteration of each PI used for the Inspect & Adapt workshop, technical debt, and preparing for the next PI Planning event.
Inspect & Adapt (I&A)	A structured retrospective at the end of each PI where the ART measures what it actually delivered against what it planned and identifies systemic improvements for next time.

Why PI Planning is different (and harder) than sprint planning

PIs and Sprints come from the same Agile DNA. SAFe takes usual agile practices like iterative delivery, timeboxed cycles, and a definition of done and stretches them to work across dozens of teams instead of just one. That’s why they feel so similar at first glance, even though there’s still plenty that sets them apart.

Dimension	Sprint / Iteration	Program Increment (PI)
Scope	One Agile team	Multiple Agile teams working together
Purpose	Deliver short-term increments of value	Align delivery across teams toward shared outcomes
Typical Duration	Strict 1‑ to 4‑week container	A fixed window of 8–12 weeks (typically 4–6 iterations).
Participants	Individual Scrum or Agile team	Agile Release Train (ART), typically 50–125 people + all engaged parties (stakeholders, Product Owners and Managers, Scrum Masters)
Planning Event	Sprint Planning (more frequent cycles)	PI Planning (longer planning rhythm)
Primary Artifact	Sprint Backlog + Sprint Goal	PI Objectives + Program Board + dependency plan
Planning Horizon	Immediate execution	Medium-term forecasting and coordination
Dependencies	Mostly within the team	Frequently cross-team
Output	Working increment	Coordinated progress toward broader business goals

In practical terms, Sprints deliver product, while PIs deliver alignment that lets those products fit together.

A PI is not a longer Sprint, and treating it like one is a common mistake. It fails because:

• A longer Sprint would hide feedback loops for weeks.
• No single team can plan 12 weeks of detailed tasks — the uncertainty is too high.
• A PI's real value is cross-team coordination, not the length of the timebox.

Circling back to the “harder” part, PI Planning is a taller order compared to sprint planning because it’s answering a much bigger question: can 50–125 people across multiple teams align on a realistic quarterly outcome, with dependencies mapped, risks ROAMed, capacity balanced, and business value clearly prioritized?

What’s the ultimate goal of PI Planning?

PI Planning exists to answer a question no single team can answer on its own: can we deliver something this big together?

A single agile team can be excellent at sprint planning and still ship something useless because two teams built incompatible versions of the same thing or because nobody flagged a shared risk. PI Planning exists to catch those problems before the work begins. The expected outcomes of PI Planning are always the same: aligned teams, mapped dependencies, owned risks, and a plan grounded in real capacity.

Three things make that possible:

• Team collaboration and alignment so all the teams understand what they're building, why it matters to the business, and how it connects to what other teams are building.
• Realistic commitments, grounded in actual team capacity.
• Identifying dependencies and risks, mapped and owned before the PI starts.

There's a fourth thing that rarely makes it into official descriptions of PI Planning, but matters just as much in practice: the plan has to be clear and visible to everyone. As an Agile Release Train grows, this becomes harder than it sounds. What works as a single shared program board for three teams starts fragmenting into a dozen disconnected views once you're coordinating multiple teams. The bigger the train, the more deliberate you have to be about keeping one source of truth instead of nine almost-matching ones.

The anatomy of a PI Planning event

PI Planning follows a standard two-day PI planning agenda. Most confusion during a PI planning session comes from people not knowing why they're in the room for a given block or what's expected of them once they get there. This shows up most with business stakeholders and operational folks who sit through Business Context without knowing if they're meant to listen, contribute, or just stay out of the way.

So before the agenda itself, here's the logic behind it: Day 1 builds shared context and produces a rough, honest draft. Day 2 fixes what's broken in that draft and turns it into a plan the agile release train actually commits to.

Preparing for PI Planning

The two days of PI Planning are really just the reveal. Most of what makes a PI planning event work happens before anyone's in the room — weeks before the upcoming Program Increment begins. The pre-PI planning work usually falls to the Release Train Engineer's and Product Management.

Four things need to be in place before the event for a successful PI Planning event:

• The backlog is ready. Features are prioritized by Product Management using a Weighted Shortest Job First (WSJF) model, so teams arrive already knowing what matters most.
• The strategy is aligned. Business context, vision, and the top program backlog features get drafted ahead of time so the meeting starts from a clear direction instead of a blank slate.
• The logistics are handled. The RTE locks the agenda, secures a venue or virtual platform, and coordinates everything needed to conduct PI Planning at scale, whether the ART works in a single location or across distributed teams.
• Tools are ready and checked. Whatever board or platform the ART plans on, it needs to be set up and tested with scale in mind. A setup that works fine for three teams can fall apart fast once you're coordinating eight or nine.

During the event, Product Managers present the vision roadmap and the highest-priority features from the program backlog. Agile teams then work out what they can realistically commit to, based on team capacity, dependencies, and technical knowledge. Ownership stays split on purpose: Product Managers own feature priorities, agile teams own story planning and estimates, and System Architects circulate the room to keep the technical work grounded in reality.

Day 1 agenda: Where are we going?

Day 1 is for context and calibration. Leadership, architects, Product Management, and the teams doing the actual work need to arrive at a shared strategy, vision, vocabulary, and understanding of what the next two days are actually for.

• Business Context. Leadership presents the current state of the business and the strategic themes for the upcoming PI.
• Product/Solution Vision. Product Management lays out the top 10 features, highlighting what moves the needle for the customer.
• Architecture Vision & Common Tools. Architects explain the technical guardrails and enabling work that will support these features.
• Team Breakouts #1. It's the core part of the day. Agile teams gather to draft initial plans, estimate capacity, identify initial dependencies, and start populating the draft plan.
• Draft Plan Review. A rapid-fire sync where teams present their best-guess plans. The goal is to surface friction points, over-capacity issues, and gotchas while there's still a full day to fix them.

During team breakouts, teams decide what work they'll take on, in what order they'll deliver it, and which other teams they depend on. Planyway is a cross-project timeline and capacity planning workspace for Jira that turns those decisions into an executable delivery plan. It maps work across sprints and calendars, aligns plans with actual team capacity, visualizes dependencies, and surfaces scheduling conflicts across projects before execution begins.

Day 2 agenda: How do we get there?

Day 2 is for refinement and commitment. Now the goal is to turn the draft into a real plan and to make sure nobody's signing up for something they can't deliver.

• Management Review & Problem Solving. Leadership and stakeholders huddle to address the “nightmare scenarios” raised during Day 1's review.

• Team Breakouts #2. Agile teams adjust their plans based on overnight feedback, finalize their PI Objectives, and secure commitments from other teams.

• The Program Board (aka the ART Planning Board). Every team presents their final iteration plans on one board.

• ROAMing Risks. Teams present their final plan and explicitly map every dependency. Every identified risk gets categorized using ROAM:

  • Resolved: The risk is handled.
  • Owned: Someone is responsible for it (and "someone" has a name, not just a label).
  • Accepted: The risk is real, but the impact is acceptable.
  • Mitigated: There's a concrete plan to reduce the impact.

  Together with the Confidence Vote, this block becomes the built‑in feedback and risk assessment moment of the whole event.

• Confidence Vote. Every participant votes on their confidence in the plan. If the average comes in below 3, the team keeps iterating until it doesn't.

The 24‑hour rule: what happens after PI Planning

PI Planning is one of the most resource-heavy events in the SAFe calendar. It takes weeks to prepare, two full days to run, and pulls every team away from their normal work. So the question everyone quietly asks is, 'How do you make sure all that effort doesn't go to waste?’ The answer comes down to what happens in the 24 hours after the event ends.

Here are a few things that separate teams that keep the plan alive from teams that watch it fade:

• Move the board into team backlogs immediately. PI Objectives and dependencies need to land in each team's actual Jira backlog within a day or two. The longer that gap, the faster the plan drifts from what people are actually doing.
• Give every ROAMed risk a real owner. Every risk needs a specific name attached to it — and a deadline for the first real check-in on that risk. Make sure the key team members responsible for each dependency and risk are named explicitly.
• Settle your capacity math. Two questions trip up almost every ART sooner or later: How do you handle velocity for a team that's brand new or just lost half its members, and does the IP Iteration count toward the average at all? Decide once and write it down.
• Set the cadence for tracking dependencies. Lock in how cross-team dependencies get monitored — a recurring Scrum of Scrums, a shared dashboard, a weekly check-in.
• Make sure the plan stays visible. Business stakeholders, supporting teams, and everyone who wasn't in the room need a clear, accessible version of what got committed. That shared view becomes the single place where you track progress against PI commitments over the entire increment.

The most common (and most frustrating) failure point is an unprepared handoff after the event. Plans built in Jira Align, Confluence Whiteboards, or sticky notes often can't be exported in a structured way. Please, take time to figure out ahead how — and with what resources — you'll handle this critical step of PI Planning.

Who should be part of a PI Planning meeting?

Officially, PI Planning includes a defined set of participants across the Agile Release Train (ART) — the ART teams that practically plan and deliver the work. However, the unwritten SAFe “rule” is that the people who do the work plan the work. So, it usually involves everyone who has a real stake in the outcome, including cross-functional teams, additional stakeholders and supporting functions, so everyone in charge of the delivery, prioritization, and decision-making stay in the loop.

That said, every ART has a baseline cast that shows up regardless of company size or industry:

• Release Train Engineer (RTE) — Owns and facilitates the entire event, while also keeping timeboxes and making sure the agenda actually happens.
• Business Owners — Score PI Objectives for business value, participate in trade-off decisions, and validate that what's being committed actually matters.
• Product Management — Presents the vision and the prioritized Program Backlog.
• System Architects / Engineering — Cover the Architecture Vision, surface technical constraints and keep plans technically grounded.
• Product Owners — Each team should have one to prioritize the team's backlog and represent its interests during planning.
• Scrum Masters — Keep their team's plan honest by facilitating team breakouts and helping surface dependencies and risks.
• Agile teams (developers, QA, UX, DevOps) — Estimate work, identify dependencies, and commit to PI Objectives.
• Additional stakeholders & supporting functions — Anyone with a genuine stake in the outcome who isn't part of a core team. Their role isn't always to plan their own work; sometimes it's to flag a dependency or to surface a particular risk.

What are the core artifacts of the PI Planning process?

Every PI Planning event produces the same four artifacts. They emerged as the minimum viable output of PI Planning and represent the smallest set of documents that can actually change how teams will work during the next quarter. Some organizations track a few extras on top, like iteration-level plans or business value scores, but these four are the core.

PI Objectives

PI Objectives define the what of the PI. They represent concise, specific commitments from each team regarding deliverables, with scores reflecting their business value as determined by Business Owners. Usually, PI Objectives are split into committed PI objectives (the team will hit these) and stretch objectives.

Program Board

The Program Board maps how it all fits for the PI. It's the one place where the whole train can see the plan at once — a single visual that surfaces features, milestones, and cross-team dependencies across the entire ART. In practice, the Dependency map needs a dedicated owner responsible for keeping it as one source of truth. Without that, it tends to break down, quietly fragmenting into a dozen almost-matching tabs that no one fully trusts.

Dependency map

Dependency map makes the who's waiting on whom of the PI impossible to ignore. This is where inter-team dependencies get made explicit at the planning stage. Catching them mid-iteration costs incomparably more than surfacing them at a whiteboard a couple of weeks earlier.

ROAM board (risk management)

And finally, the what could break it of the PI. Every identified risk gets sorted into Resolved, Owned, Accepted, or Mitigated — forcing a decision on each one instead of letting it sit as an open question for the whole quarter.

What are the common pitfalls of PI Planning?

SAFe documentation flags a few common failure points for PI Planning. In practice, the list looks a bit different. Some of the usual suspects show up in almost every struggling ART, while others rarely make the official list but are just as damaging

Teams walk into the room unprepared

If the Program Backlog isn't prioritized and the business context isn't drafted before Day 1, teams spend the morning waiting for direction instead of planning. By the time real planning starts, there's a full day less of it left.

The System Demo shows slides, not software

The System Demo happens at the end of each PI to show what was actually built before committing to the next round of planning. Whenever it's built from slides instead of working software, the room gets a false sense of progress and the next PI gets planned around what was said to be delivered, not what actually was.

PI Objectives describe work, not outcomes

Objectives that read like a feature dump — not business outcomes — turn the PI Planning session into another status meeting. If a Business Owner can't explain why an objective matters, it probably shouldn't be committed to.

I&A gets cut to save time

Cutting I&A to save time ensures the same problems come back next PI. The cadence is non-negotiable: plan → execute → inspect.

The planning tool gets chosen the week of the event

This one rarely makes official pitfall lists, but it's one of the most common questions teams run into. The tool shapes how teams think and work at every stage of the PI. How that specific tool will be configured, who owns it, and how teams will actually use it during the event — all of that needs to be worked out during preparation.

No one owns the plan after the room clears

The artifacts only work if someone is explicitly responsible for keeping them current throughout the PI. This someone should have a clear understanding of how to adapt the plan as conditions change and the tools in place for the ART to review it together on a regular cadence.

How Planyway helps teams follow through on PI commitments in Jira

If you use Jira as your ticketing system, you already know that its finicky interface can sometimes feel too much for the team, especially if we’re talking about the leadership. During PI Planning, Jira often hides the actual roadmap, leaving stakeholders struggling to grasp the plan while teams get bogged down in technical overhead.

Planyway for Jira helps you build a PI plan that is not just a theoretical, hard-to-read document, but a practical, achievable, and live reflection of your teams' actual capacity and the project's real-time dependencies that everyone on the team understands.

With Planyway, you can:

Keep the plan connected to its source

Connect multiple Jira projects into a single, comprehensive timeline for the whole PI, with epics, features, milestones, and sprints mapped on one timeline for cross-team planning.

Give stakeholders a portfolio view, without making them dig through tickets

Build a portfolio roadmap that tracks high-level progress for business stakeholders, teams, and leadership. The roadmap can be grouped by the way you work — epics, projects, initiatives, or quarter.

See cross-project dependencies before they cause a conflict

Link related tasks across teams and visualize inter-team dependencies directly on the timeline.

Catch overload before it becomes a missed commitment

View each person's workload on the timeline, including time off, and spot overloads early. If someone's buried, you can just drag and move the ticket to another team member or a different sprint.

Wrapping up: make the next PI Planning count

PI Planning isn't getting simpler: more teams, dependencies, business context to align on every quarter. But if you own the habit and a structured process of getting the right people in the room, turning vague ambition into specific PI Objectives, building a Program Board, and staying on top of risk management, you'll always have a clear plan and the tools to hold the ART accountable to it.

The teams that get real value out of program increment planning know very well how the plan survives contact with actual Jira tickets, real team members's capacity, and the dozen other planning events competing for everyone's attention over the next 8–12 weeks.