Knowledge
Two days in which every team agrees what will actually be built over the next three months.
This page explains what a PI Planning is, who attends, how the two days run and where it fails in practice. It is written from facilitating these events, not from a textbook — including the question of when external facilitation is worth it and when it is not.
A PI Planning is the event in which all teams of an Agile Release Train jointly agree the scope of work for the next Planning Interval. It usually runs for two days and takes place roughly every twelve weeks, in many organisations once a quarter.
What separates it from any other planning round: teams do not plan one after another and not separately, but at the same time and in the same room. Dependencies between teams become visible where they arise — not six weeks later in a status report.
Because the scope of every team for a whole quarter is settled here, significant business decisions are effectively made during a PI Planning. That is why the event deserves more attention than it gets in many organisations: it is not an appointment in a calendar, it is the bottleneck of agile planning.
PI Planning is also called big-room planning or quarterly planning. “PI” originally stood for Program Increment; since SAFe 6.0 the period is called a Planning Interval. The abbreviation stayed.
A Planning Interval is the period a PI Planning plans for: usually around three months, divided into several sprints of two to four weeks each. At the end of the interval the cycle starts again with the next PI Planning.
Up to SAFe 5 this period was called a Program Increment. SAFe 6.0 renamed it to Planning Interval, because “increment” describes a result rather than the span of time in question. In many companies both terms are still in use side by side — they mean the same thing.
A PI Planning brings together everyone needed to plan the next interval. Size varies accordingly: from around fifty people for a small train to several hundred in large organisations.
| Role | Task in the PI Planning |
|---|---|
| The teams | Plan their own work — present in full, not through representatives. |
| Product Owners and Product Management | Bring the prioritisation and answer the questions that come up when the work gets cut into pieces. |
| Scrum Masters | Facilitate the work inside their team, hold the timebox and surface dependencies. |
| Release Train Engineer | Leads the train through the interval — during the planning both host and facilitator. |
| Business Owners and stakeholders | Provide the business context and assess the plans at the end. |
| System architecture and management | Set the technical guardrails and clear impediments no single team can resolve. |
Two things decide the quality of the round. First: whoever plans the work has to do it later — delegated planning rarely survives to the end of the interval. Second: across these two days the RTE is host and facilitator at once. That double load is exactly what can be handed over, and without Business Owners in the room who can actually decide, the planning ends without commitment.
Anyone who cannot be on site joins remotely. That works — but only if remote participation is planned from the start rather than improvised on the morning of day one. One camera in the room is not enough.
The flow follows a well-worn pattern: shared context first, then planning inside the teams, then alignment between the teams and, to close, a shared commitment from teams and management.
The morning belongs to the shared picture: where the business stands, what the product vision is, which technical guardrails apply, how planning will work. In the afternoon teams withdraw and produce their first draft plans. The day ends with a review of those drafts and with management taking on the problems that surfaced, so decisions can be prepared overnight.
The second day starts with the adjustments that follow from the previous evening. Teams then keep planning, present their final plans and name the risks they see. Finally everyone votes on how confident they are in the plan. If the result comes out too low, the plan is reworked — not talked up.
| Agenda item | What happens in it |
|---|---|
| Day 1 · Business Context | The business side shows where the company stands and what counts in the coming interval. |
| Day 1 · Product / Solution Vision | Product management presents the next priorities and the features coming up. |
| Day 1 · Architecture Vision | System architecture names the technical guardrails and the rebuilds that are due. |
| Day 1 · Planning Context | The Release Train Engineer explains the mechanics: schedule, capacity, expected outputs. |
| Day 1 · Team Breakouts | Teams plan their own work, estimate their capacity and name their dependencies. |
| Day 1 · Draft Plan Review | Each team presents its draft — objectives, dependencies and the risks it sees. |
| Day 1 · Management Review & Problem Solving | Management takes on the problems that surfaced and prepares decisions overnight. |
| Day 2 · Planning Adjustments | The previous evening's decisions are presented: changed scope, priorities, capacity. |
| Day 2 · Team Breakouts | Second round: teams finish their plans on the basis of those adjustments. |
| Day 2 · Final Plan Review | The final plans are presented and assessed by the business owners. |
| Day 2 · ART Risks | The remaining risks are named openly and each one is given an owner. |
| Day 2 · Confidence Vote | Everyone votes on how confident they are in the shared plan. |
| Day 2 · Plan Rework | If the vote comes out too low, the plan is reworked — not talked up. |
| Day 2 · Planning Retro & Moving Forward | A short retrospective on the event, then the next steps for the interval. |
The same agenda, extended by an optional preceding day for travel, team building or a training session, is on the homepage under Extended PI Planning agenda.
If everyone is travelling in anyway, the evening before is the cheapest opportunity for team building, a training session or a company celebration that otherwise never happens. One trip, two results — the travel costs are incurred either way.
A PI Planning is not won during the two days but in the weeks before. Whatever has to be improvised on the day costs planning time the teams then no longer have.
Business context, product vision and prioritisation are agreed before the planning — they are not its subject. Negotiating scope in the room costs you the first day.
Work has to be prepared well enough for teams to split it across sprints. Coarse topics without a recognisable size block the breakouts.
Complete teams, Business Owners with decision-making authority, architecture available. “If nothing comes up” is not a commitment.
Room, technology, catering, travel, accommodation and the remote setup. It sounds like a side issue and still decides whether anyone is still able to concentrate in the afternoon.
The patterns repeat across organisations. None of them is a planning mistake by the teams — they all originate before or beside the event.
When stakeholders use the planning to reopen priorities, teams plan against a moving target. You can tell because day one ends without a workable draft.
Problems that management would have to resolve end up in a list instead of a decision. You can tell because the same items reappear at the next planning.
If low confidence is noted rather than acted on, everyone learns the vote has no consequences. After that nobody votes honestly again.
Teams plan next to each other instead of with each other. You can tell because dependencies only surface during the sprint — when they are expensive.
Steering the train, running the agenda, minding the technology and contributing to decisions at once means doing none of it well. It is the most common cause and the easiest one to fix.
Participants joining without their own facilitation, without working audio and without access to the same artefacts are not really part of the planning — they are an audience.
Not every PI Planning needs facilitation from outside. The honest answer depends on where the difficulty actually sits.
… the Release Train Engineer facilitates and is needed for content at the same time. … it is an organisation’s first PI Planning and nobody has run the format before. … logistics drive the effort, because hundreds of people have to travel, be accommodated and be fed. … recent plannings were fine on substance but felt exhausting and thin on results. … a neutral person is needed because there is conflict between departments in the room.
… the planning works and the RTE has enough capacity. Then external facilitation costs money and adds nothing. … the real problem sits upstream: unclear prioritisation, an unprepared backlog, missing decision-making authority. Facilitation makes those visible, it does not solve them. … the organisation has no Agile Release Train yet. Then the question is not facilitation but how the teams are cut.
The second case is the more common one. If you are unsure which one you are in, a conversation settles it faster than a proposal.
Classically two days. With a preceding day for travel, team building or training it becomes three. Shorter than two days rarely works: the second day exists so teams can react to the problems of the first.
Roughly every twelve weeks, in many organisations on a quarterly rhythm — each time at the start of a new Planning Interval.
As many as belong to the train. Frequently between fifty and two hundred people; large organisations run several trains in parallel.
Yes, but it is the harder variant. Remote works when facilitation is designed for it, every team has its own facilitator and everyone works with the same artefacts. Treated as a cost-saving measure it usually fails — much of the event’s value sits in the conversations between the sessions.
No. The format comes from SAFe and carries its vocabulary, but the underlying idea — all teams planning together for the same period — also works in organisations using a different scaled framework or none at all.
They are the same period under two names. SAFe 6.0 renamed Program Increment to Planning Interval. The abbreviation PI was kept, which is why the event is still called PI Planning.
This page is written from practice: from October 2023 to October 2024, quarterly PI Plannings for around 180 people of the Digital Business Unit of KION AG, alongside accompanying agile transformations — currently at a German federal authority as part of an IT systems house mandate.
If you would like to hand over the facilitation, the preparation or the whole organisation, the bookable services are on the homepage under PI Planning as a Service — from facilitation only through venue to full travel and catering organisation.