What Is PI Planning? A Practical Guide to Program Increment Planning in SAFe

What is PI planning?

PI planning (Program Increment planning) is a recurring two-day event in the Scaled Agile Framework (SAFe) where all teams on an Agile Release Train - typically 50 to 125 people across five to twelve teams - plan the next 8–12 weeks of work together. Each team leaves with committed objectives for the increment, and the train leaves with a program board showing every cross-team dependency and milestone.

The full form of PI is Program Increment, though SAFe 6.0 renamed it to Planning Interval - deliberately keeping the abbreviation, so both terms refer to the same thing. Either way, PI planning is the heartbeat of the framework: it happens on a fixed cadence, everyone attends, and the next one is scheduled before the current one ends.

The reason it exists is scale. Sprint planning aligns one team for two weeks. Nothing in plain Scrum aligns ten teams for a quarter - so at scale, dependencies between teams surface as blockers mid-increment rather than as lines on a board before work starts. PI planning is the mechanism that moves that discovery to day one.

What is a program increment?

A program increment is a fixed timebox, usually 8–12 weeks, in which an Agile Release Train delivers working, tested value. The most common shape is five iterations: four development sprints plus one Innovation and Planning (IP) iteration at the end.

Think of it as a sprint for the whole train: long enough for meaningful features to ship, short enough that the plan doesn't rot before it's revisited. The IP iteration is the shock absorber - it hosts the next PI planning event, gives teams hackathon and improvement time, and quietly serves as the buffer that keeps one team's overrun from cascading into the next increment.

Where does PI planning fit in SAFe?

In the Scaled Agile Framework, PI planning is the essential ceremony - SAFe's own guidance is blunt that if you're not doing it, you're not doing SAFe. It sits at the boundary between increments and is the point where strategy meets execution: portfolio priorities and product vision come in, team-level commitments come out.

The unit that plans is the Agile Release Train (ART): a long-lived team of agile teams building one product or value stream. The Release Train Engineer facilitates, product management brings the vision and the top features from the ART backlog, system architects bring the technical direction, and business owners show up to assign value and arbitrate trade-offs.

If your organization doesn't run SAFe, you may still recognize the event - many teams run 'big room planning' or quarterly planning with identical mechanics and none of the certification. The advice in the rest of this guide applies equally there.

What does a PI planning agenda look like?

The standard PI planning agenda runs two full days. Day 1 sets context and produces draft plans; day 2 turns drafts into commitments. The usual flow:

• Day 1, morning - business context from leadership, then product/solution vision from product management: what matters this increment and why.
• Day 1, midday - architecture vision and development practices, then planning context: how the two days will run and what a finished plan looks like.
• Day 1, afternoon - team breakout #1: each team estimates its capacity per iteration, pulls features into iterations, drafts PI objectives, and flags every dependency on another team.
• Day 1, end - draft plan review in front of everyone, followed by a management review after hours to resolve the problems the drafts exposed.
• Day 2, morning - planning adjustments announced, then team breakout #2 to rework plans against them.
• Day 2, midday - final plan review; business owners assign business value to each team's objectives.
• Day 2, afternoon - remaining risks are ROAMed (resolved, owned, accepted, mitigated), the room takes a confidence vote, plans are reworked if confidence is low, and a short retrospective closes the event.

The team breakouts: where PI planning succeeds or fails

Everything outside the breakouts is broadcast; the breakouts are the plan. And the two numbers that decide whether that plan survives contact with the increment are estimated size and available capacity. Teams that size features by comparison against shipped work - the discipline behind story points - and check capacity against real availability produce plans that hold. Teams that eyeball both produce plans that fail in week three, at scale, in front of everyone.

Capacity is the one most often faked. A team of six is never six FTEs - it's four and a half after support rotations, holidays, and the specialist who's half-lent to another team. Planning against a real resource allocation view instead of headcount is the single cheapest improvement most trains can make to their PI planning.

What are the outputs of PI planning?

PI planning produces two artifacts: a set of committed PI objectives per team, each with a business value assigned by business owners, and a program board mapping features, cross-team dependencies, and milestones across the iterations of the increment. A confidence vote on the whole plan goes on record alongside them.

The program board is the one that earns the event its cost. It's the wall of string between sticky notes - every red line is a dependency that would otherwise have been discovered as a surprise blocker. This is fundamentally a dependency visualization problem: the board is only useful while the dependencies on it are current. You can build one in the browser with our free PI planning board - it flags backwards dependencies and over-capacity iterations live as you place the cards.

The confidence vote deserves respect rather than theater. Fist of five, whole room; if the average is below three, the plan gets reworked on the spot. A train that never votes below four isn't confident - it's polite.

What happens before and after PI planning?

Before the event: content readiness - a refined ART backlog with the top features actually estimable - plus logistics and, when multiple trains build one solution, a pre-PI planning event to align inputs across ARTs. After it: post-PI planning synchronizes the trains, teams feed their objectives into iteration planning, and the program board becomes the tracking artifact for the increment.

Preparation is most of the outcome. Walking ninety people through an unrefined backlog doesn't produce a plan; it produces a very expensive estimation workshop. If the features going in haven't been sized and split, the breakouts get spent doing backlog refinement in the most expensive room the company ever books.

How is PI planning different from sprint planning?

Sprint planning aligns one team for one iteration of one or two weeks; PI planning aligns every team on the train for a whole increment of 8–12 weeks. Sprint planning pulls stories from a team backlog; PI planning distributes features across teams and surfaces the dependencies between them before they become blockers.

• Scope: one team versus the entire train (5–12 teams).
• Horizon: one sprint versus a full program increment.
• Inputs: a refined team backlog versus vision, roadmap, and the top ART backlog features.
• Outputs: a sprint backlog versus PI objectives plus a program board of dependencies.
• Cadence: every one to two weeks versus every eight to twelve.

How do you run remote or distributed PI planning?

Remote PI planning replaces the big room with a shared digital workspace: video for the ceremonies, a virtual program board for the plan, and live capacity and dependency data instead of sticky notes. Distributed trains usually split the agenda across three or four shorter days so no timezone plans at 3 a.m.

Two adjustments matter more than the rest. Record the business context and vision briefings so they can be watched asynchronously - spending shared-timezone hours on broadcast content is a waste of the scarcest resource in the event. And accept that the digital board is no longer a substitute for the wall; it is the single source of truth, which is an upgrade, provided you pick tooling the teams will keep updating after the event ends.

What tools do you need for PI planning?

The minimum toolset is a program board for dependencies (physical or digital), a per-team, per-iteration capacity view, and a backlog with features refined enough to estimate. In practice most trains use a backlog tool like Jira or Azure DevOps plus a whiteboard tool like Miro for the board itself - and hit the same failure mode: the board is a photograph by the end of week two.

A photograph of a plan is not a plan. The event's outputs only pay for themselves if they stay alive for the whole increment - dependencies that reschedule downstream work when a feature slips, capacity that reflects who is actually allocated where rather than headcount. That living-plan territory is what AxioPlan is built for: gantt-style dependency management with automatic rescheduling, and resource allocation that shows real availability per iteration. For the estimation half of the breakouts, our free story point calculator gives teams a defensible starting size for unfamiliar features.

Final thoughts

PI planning is expensive on purpose - two days of everyone's time, four times a year, is the price of discovering dependencies on a board instead of in production. Whether the event repays that price is decided by two things: how honest the capacity numbers in the breakouts are, and whether anyone looks at the program board again after day two.

Run it lighter than the textbook if you like - plenty of successful teams do quarterly big-room planning with half the ceremony. Just keep the two outputs that matter: objectives a team actually believes in, and a dependency board that's still true in week six.