PI Planning is the cadence-based event in the Scaled Agile Framework (SAFe) where all the teams of an Agile Release Train (ART) plan the next Planning Interval together, face to face or virtually. It typically lasts two days, takes place every 8–12 weeks and ends with committed PI objectives and an ART planning board that shows feature delivery dates and dependencies.
WWG ran its first fully remote PI Planning in December 2020, with the development, marketing, sales and post-sales teams planning together over video conference. This guide keeps what we learned then and updates it to the current SAFe 6.0 terminology: what PI Planning is, who takes part, the two-day agenda, risks and the confidence vote, how it differs from sprint planning, and how to run it with hybrid teams.
TL;DR / Key Takeaways
- PI Planning aligns every team on an ART to one plan for the next Planning Interval, usually 8–12 weeks long.
- The Release Train Engineer facilitates it; Business Owners, Product Management, architects and all Agile Teams attend.
- The standard agenda runs over two days: business context and vision, two rounds of team breakouts, management problem-solving, final plan review, risks and a confidence vote.
- The two outputs are committed PI objectives, with business value assigned by the Business Owners, and the ART planning board.
- Remote and hybrid PI Planning works when preparation is thorough and the digital tools are ready before day one.
What is PI Planning in SAFe?
PI Planning is the event in which an entire Agile Release Train plans the next Planning Interval (PI) together. In SAFe 6.0 the PI is a Planning Interval, formerly called Program Increment. SAFe describes the event as essential: "If you are not doing it, you are not doing SAFe." It usually lasts two days and repeats every 8–12 weeks.
A PI is a cadence-based timebox in which Agile Release Trains deliver value to customers in alignment with their PI objectives. The most common pattern is four development iterations followed by one Innovation and Planning (IP) iteration. PI Planning takes place during the IP iteration, so it does not take capacity away from the development iterations.
The event applies a principle of the Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." The people who do the work plan the work, together.
"Resistance to change is the biggest obstacle to overcome"
Chris Paine
Why does PI Planning matter for a growing organisation?
PI Planning matters because it turns many separate team plans into one committed plan that everyone has seen. It aligns development to business goals, exposes dependencies between teams before they cause delays, matches demand to real capacity and forces fast decisions, because business owners and teams are in the same room at the same time.
Lean transformation relies on methods and tools, but its effectiveness depends on how people in the organisation work together. Resistance to change is normal: people need to see waste and downtime disappear before a new way of working sticks.
That was the test for WWG in 2020. For years we had encouraged clients to adopt an agile framework in our custom software development projects; running PI Planning on ourselves was the moment to move from theory to practice. If you are new to the underlying ideas, start with our guide to agile methodology.
Who takes part in PI Planning?
The whole Agile Release Train takes part. The Release Train Engineer (RTE) facilitates the event, Business Owners set the business context and assign value to objectives, Product Management presents the vision and priorities, System and Solution Architects present the architecture vision, and every Agile Team plans its own work, supported by the System Team.
- Release Train Engineer (RTE): schedules and facilitates the event, presents the planning process and leads the risk review and the retrospective.
- Business Owners: describe the state of the business, review draft plans and assign business value to each team's PI objectives.
- Product Management: presents the product or solution vision, usually as the top ten or so upcoming features.
- System Architect: presents the architecture vision and any changes to development practices.
- Agile Teams: estimate capacity, plan iteration by iteration, identify risks and dependencies and commit to objectives.
What are the inputs and outputs of PI Planning?
The inputs are the business context, the roadmap and vision, and the highest-priority features of the ART backlog. The outputs are two: committed PI objectives, a set of SMART objectives for each team with business value assigned by the Business Owners, and the ART planning board, showing feature delivery dates, dependencies and milestones.
The ART planning board was called the program board in earlier versions of SAFe. Teams also define uncommitted objectives: goals built into the plan but not committed to because of too many unknowns. They are not extra work for spare time; they make the plan more reliable and give management early warning of what may not be delivered.
After the event, the RTE and stakeholders summarise the team objectives into ART PI objectives, which are used to communicate externally and track progress. If your organisation already works with OKRs, this is where they connect: see what OKRs are not for how to keep the two consistent.
What does the two-day PI Planning agenda look like?
The standard agenda runs over two days. Day one sets the context and produces draft plans, which management reviews in the evening. Day two adjusts the plans, finalises objectives, reviews all plans together, deals with risks, runs the confidence vote and closes with a retrospective. ARTs spread across time zones can extend the timebox.
| Day | Session | What happens | Led by |
|---|---|---|---|
| 1 | Business context | Current state of the business and the portfolio vision | Business Owner or senior executive |
| 1 | Product/solution vision | Top upcoming features and changes since the last PI | Product Management |
| 1 | Architecture vision and development practices | Architecture vision and practice changes such as test automation or CI/CD | System Architect, development manager |
| 1 | Planning context | The planning process and expected outcomes | RTE |
| 1 | Team breakouts #1 | Capacity per iteration, draft plans, risks, dependencies, draft PI objectives | Agile Teams |
| 1 | Draft plan review | Teams present capacity and load, draft objectives, risks and dependencies | Teams, reviewed by Business Owners |
| 1 | Management review and problem-solving | Adjust scope, people and resources to reach achievable objectives | Management, RTE |
| 2 | Planning adjustments | Management presents changes to scope, people and resources | Management |
| 2 | Team breakouts #2 | Final objectives; Business Owners assign business value | Agile Teams, Business Owners |
| 2 | Final plan review | Each team presents its plan, risks and impediments | Agile Teams |
| 2 | ART PI risks | Risks are discussed openly and ROAMed | RTE |
| 2 | Confidence vote and plan rework | Fist-of-five vote; rework until confidence is high | All teams |
| 2 | Planning retrospective | What went well, what did not, what to do better | RTE |
A moment of the WWG PI Planning of December 2020
How are risks handled during PI Planning?
Risks are collected from every team during the final plan review and discussed openly in front of the whole train. Each one is then placed in one of four ROAM categories: Resolved, Owned, Accepted or Mitigated. The aim is not to eliminate every risk but to make sure nobody leaves the event with a hidden one.
- Resolved: the teams agree the risk is no longer a problem.
- Owned: someone takes responsibility for the risk, because it cannot be resolved during planning.
- Accepted: some risks are facts or potential problems that must be understood and accepted.
- Mitigated: the teams identify a plan to reduce the impact of the risk.
Risks that teams cannot solve alone are addressed in a broader management context. In our experience, each risk also needs a short explanatory text, because a one-line sticky note is rarely enough.
How does the confidence vote work?
Once the risks have been addressed, each team votes on its confidence in meeting its PI objectives by raising one to five fingers, the "fist of five". If the average is three or more, management accepts the commitment; if it is below three, the team reworks its plan. The vote is then repeated for the whole ART.
Anyone voting two fingers or fewer is invited to explain why. Their concerns may add to the risk list, require replanning or simply provide information.
If needed, plan rework follows, one of the few occasions where commitment matters more than the timebox. In our 2020 event, the WWG marketing team used this stage to define the resources for each objective, both people and anything needed to support them.
Another moment of the PI Planning of the WWG marketing team
How is PI Planning different from sprint planning?
Sprint planning is one team's event to plan a sprint of one month or less, timeboxed to at most eight hours for a one-month sprint. PI Planning brings every team on the train together for about two days to plan a full Planning Interval, including dependencies between teams and the business value of each objective.
The two work at different levels. PI Planning sets the objectives and the cross-team plan for the interval, and each team then runs iteration planning at the start of every iteration to detail the work.
How do you run PI Planning with remote and hybrid teams?
Remote and hybrid PI Planning works when the preparation is done in advance and every team uses the same digital tools. SAFe states that real-time, concurrent virtual planning has proven effective when physical presence is not possible. The critical points are a shared digital planning board, reliable video, and a digital way to run the confidence vote.
In December 2020 WWG planned everything over video conference. We used Jira for epics, stories, tasks and sprints; Big Agile, integrated with multiple Jira projects, as a shared planning board for goals, sprints and dependencies; Microsoft Teams for calls and one channel per team; and Voting Poker to run the confidence vote online. Today the same roles are commonly filled by Jira Align, which supports SAFe among other scaling frameworks, and online whiteboards such as Miro for the planning board.
What worked for us: with good pre-planning, the remote event was as efficient as an in-person one, with fewer distractions and a master document showing the whole scope and dependencies. There were no travel or accommodation costs, and excess work in progress was reduced.
We did it! Our first distributed and completely remote PI Planning. Is it goodbye to sticky notes, or just see you later?
What was harder: coordination grows with every team involved (we had four), and teams with many dependencies are difficult to align. Blocking all teams for two days is costly, side conversations disappear and the confidence vote is harder to run remotely. People also tend to follow the shared screen passively, so facilitation must invite participation.
What should a PI Planning checklist include?
A PI Planning checklist covers three kinds of readiness: organisational (the right people and decision makers are available), content (business context, vision and prioritised features are ready) and logistics (rooms or virtual spaces, tools and access). Preparation is what the two days depend on, so it starts weeks before the event.
- Organisational readiness: Business Owners confirmed for both days, RTE assigned, teams and their capacity known.
- Content readiness: business context and vision prepared, top features of the ART backlog prioritised and understood, architecture vision ready.
- Logistics readiness: rooms or video links, a shared planning board, templates for PI objectives and a way to vote.
- After the event: enter team objectives and stories in the planning tool, confirm the calendar of team and ART events, and publish the ART PI objectives.
Setting up this cadence for the first time is often the hardest part. WWG's software development process implementation service helps teams introduce agile planning practices that fit their size.
To talk through how to introduce PI Planning in your teams, write to us at business@wwg.it.
Sources
- Scaled Agile, Inc., PI Planning — https://framework.scaledagile.com/pi-planning/
- Scaled Agile, Inc., PI Planning, full article as archived on 7 June 2024 — https://web.archive.org/web/20240607154138/https://scaledagileframework.com/pi-planning/
- Scaled Agile, Inc., Planning Interval (PI) — https://framework.scaledagile.com/planning-interval/
- Agile Manifesto, Principles behind the Agile Manifesto — https://agilemanifesto.org/principles.html
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020) — https://scrumguides.org/scrum-guide.html
- Atlassian, Jira Align — https://www.atlassian.com/software/jira-align
FAQ
Frequently Asked Questions
A Planning Interval usually lasts 8–12 weeks. The most common pattern is four development iterations followed by one Innovation and Planning iteration, during which the next PI Planning takes place. The exact length is chosen by each train, but it should stay constant so that planning follows a predictable cadence.
Uncommitted objectives are goals that a team builds into its plan but does not commit to, because they carry too many unknowns or risks. They are not extra work for spare time. They increase the reliability of the plan and warn management early about objectives the train may not be able to deliver.
After the event, teams enter their PI objectives and stories in their planning tool and confirm the calendar of team and train events. The Release Train Engineer and stakeholders then combine the team objectives into ART PI objectives, which are used to communicate progress externally and to track delivery during the interval.
Yes, any group of teams with shared dependencies can use the format without every SAFe role and practice, although SAFe treats PI Planning as part of the full framework. Keep the core elements: a shared business context, team breakouts, visible dependencies, an open risk review and a confidence vote before anyone commits.
