PI Planning: Preparation, 2-Day Agenda, Outputs and Follow-Through
9 min read ยท 2026-10-25
PI planning is a recurring event in the Scaled Agile Framework (SAFe) where all the teams on an Agile Release Train meet, usually for two days, to plan the next planning interval of about 8 to 12 weeks together. They leave with team PI objectives, a board showing features and dependencies across teams, a list of risks and a confidence vote on the plan.
The event itself is only part of the work. Good PI planning depends on the weeks before it, when product management ranks the features and teams check their capacity, and on the weeks after, when the plan is tracked and adjusted. The roadmap below covers the whole cycle in six phases. It is written for release train engineers, product managers, product owners and the leaders who sponsor the event.
The roadmap at a glance
Goal: A release train runs a two-day PI planning event that ends with committed objectives for every team, a dependency board, owned risks and a confidence vote of three or more, then tracks the plan through the planning interval. Duration: 14 weeks (4 weeks of preparation and a 10-week planning interval)
Business context and feature backlog (Weeks 1-3)
Give teams a clear, ranked set of features to plan against.
- Update the vision and roadmap with business owners and product management.
- Rank the top features, for example with weighted shortest job first, and keep the list to what the train can realistically take on.
- Write a short benefit hypothesis and acceptance criteria for each top feature.
- Review architectural work (enablers) with the system architect so it competes in the same ranked list.
Milestone: A ranked list of top features, each with a benefit hypothesis and acceptance criteria, agreed by product management and business owners.
Team readiness and logistics (Weeks 2-4)
Make sure teams, rooms or remote tools and the agenda are ready before day 1.
- Ask each team to calculate its capacity per iteration, with holidays and planned leave.
- Hold pre-planning sessions where product owners walk their teams through the top features.
- Book the venue or set up the digital whiteboard, breakout rooms and the program board.
- Send the agenda and confirm that business owners, architects and shared services will attend both days.
Milestone: Capacity confirmed for every team, features pre-reviewed by teams and all key attendees confirmed for both days.
PI planning day 1 (Week 5 (day 1))
Share the context and produce a first draft plan from every team.
- Present the business context, product vision, architecture vision and planning context.
- Run team breakouts: teams split features into stories, place them in iterations and draft PI objectives.
- Review draft plans together: each team shows its objectives, risks and dependencies.
- Hold the management review and problem solving session to adjust scope or people where plans do not fit.
Milestone: A draft plan from every team, and a list of decisions from management review ready to share at the start of day 2.
PI planning day 2 (Week 5 (day 2))
Turn the drafts into a plan the teams commit to.
- Share the planning adjustments decided in management review.
- Run a second round of team breakouts and have business owners assign business value to team objectives.
- Review final plans, then address each program risk with ROAM: resolved, owned, accepted or mitigated.
- Run the confidence vote, rework plans if confidence is low, then hold a short planning retrospective.
Milestone: Final team PI objectives with business value, a complete dependency board, every risk ROAMed and an average confidence vote of three or more.
Execute and synchronize (Weeks 5-12)
Deliver the plan iteration by iteration and catch problems early.
- Hold a weekly coordination meeting across teams on progress, dependencies and blockers.
- Hold a regular product management sync on scope and priorities.
- Update the program board after each iteration and flag dependencies that are at risk.
- Run a system demo at the end of each iteration with the integrated work of all teams.
Milestone: A system demo every iteration, with the dependency board kept up to date and slipping objectives flagged to business owners.
Inspect, adapt and prepare the next PI (Weeks 13-14)
Measure what was delivered, improve the process and start the next cycle.
- Show the final system demo of the whole planning interval.
- Compare the business value delivered with the value planned for each team's objectives.
- Run a problem-solving workshop on the biggest issue, such as late dependencies.
- Use the innovation and planning iteration to refine the backlog for the next PI planning.
Milestone: Inspect and adapt held, with predictability per team reported and improvement items added to the backlog for the next PI.
A practical two-day agenda
The order of sessions matters more than the exact times. Context comes first, then teams plan, then everyone sees the result and fixes what does not fit. Below is a common starting point for an in-person event. Adjust the times to your train and keep the sequence.
Protect the breakout time. If the morning presentations run long, cut them, not the breakouts. Teams cannot commit to a plan they did not have time to build.
- Day 1 morning: business context from a senior leader, product vision and top features from product management, architecture vision and development practices from the system architect, planning context and rules from the release train engineer.
- Day 1 afternoon: team breakouts with product owners, then a draft plan review where each team presents objectives, risks and dependencies.
- Day 1 evening: management review and problem solving with business owners, product management and the release train engineer.
- Day 2 morning: planning adjustments, then team breakouts. Business owners visit each team to assign business value to objectives.
- Day 2 afternoon: final plan review, ROAM of program risks, confidence vote, plan rework if needed and a planning retrospective.
Example: PI planning for a six-team release train
Picture an insurance company with a release train of six teams working on its claims platform: claims intake, adjuster tools, payments, documents, integration and a data team. The next planning interval runs ten weeks: four two-week iterations and an innovation and planning iteration.
Notice the payments dependency on the external provider. It went on the board as a red dependency with an owner and a fallback date, which is exactly what PI planning is for: finding problems while there is still time to fix them.
- Weeks 1-3 (owner: product management): top features ranked, led by online first notice of loss, faster payouts and document upload from mobile.
- Weeks 2-4 (owner: release train engineer): capacity confirmed per team, remote board set up for two distributed teams, business owners from claims and finance confirmed.
- Day 1 (owner: release train engineer): draft plans show the payments team overloaded in iteration 2. Management review moves one data feature to the next PI.
- Day 2 (owner: teams and business owners): final objectives with business value from 1 to 10, the payments provider dependency marked as owned by the payments product owner, average confidence vote of four.
- Weeks 5-12 (owner: release train engineer and product owners): weekly coordination, system demo every iteration, document upload slips one iteration and is flagged early.
- Weeks 13-14 (owner: release train engineer): inspect and adapt shows strong predictability on committed objectives. The problem-solving workshop targets late environment setup.
Who owns what
PI planning brings many roles into one room. Confusion over who decides what wastes hours of the event. Share this list in the pre-read so everyone knows their part before day 1.
Business owners are often the hardest people to keep for two full days. Agree in advance on the sessions where they must be present: the business context, the management review, the business value assignment on day 2 and the confidence vote.
- Release train engineer: owns the event, the agenda, the logistics and the management review, and keeps the program board and risk list.
- Product management: owns the vision, the ranked feature list and the trade-offs on scope.
- Business owners: own the business context, assign business value to team objectives and accept the final plan.
- System architect: owns the architecture vision and the enabler work.
- Product owners: own the team backlogs and help teams break features into stories.
- Teams and scrum masters or team coaches: own their iteration plans, their objectives and their confidence vote.
PI objectives and the program board
PI objectives are short statements, written by each team, of what it plans to achieve in the interval in business terms. Write them so a business owner understands them without the backlog, for example "Customers can upload claim documents from a phone", not "Finish stories 412 to 431". Teams can also add uncommitted objectives: work they plan to attempt but cannot promise. Business owners rate each objective, often on a scale of 1 to 10, so the value of the plan is visible.
The program board (some versions of SAFe call it the ART planning board) shows features in the iteration where they are expected to be done, with milestones and lines between dependent items across teams. A board full of crossing lines is a warning sign. It often means team boundaries do not match the work, which is worth raising in the inspect and adapt workshop.
How to report the PI plan to leadership
Leaders who were not in the room want a short answer: what will this train deliver, what is at risk and what do you need from us. Send a one-page summary within a day of the event with the top features and the iteration each is expected in, the committed objectives by team with their business value, the top three risks with owners, and the average confidence vote.
Leave out story counts, velocity charts and the full board photo. Offer a link to the board for anyone who wants the detail. During the interval, report against the same page every two weeks so leaders see the plan change in one place, not across scattered status emails.
Running PI planning remotely or across time zones
Many trains now run PI planning fully or partly remote. The agenda stays the same, but you need a digital whiteboard such as Miro or Mural for the program board and team boards, video breakout rooms for each team and a clear channel for questions to product management and architects.
Remote events are more tiring, so shorten the plenary sessions and spread the event over more days with shorter hours if your teams are in several time zones. Test the tools with every team a week before, assign a facilitator per breakout room and keep cameras on during the confidence vote so people engage.
Common mistakes to avoid
- Walking into the event without ranked features turns day 1 into a prioritization debate, so finish the feature ranking and acceptance criteria two weeks before.
- Planning teams to full capacity leaves no room for surprises, so plan below capacity and keep the innovation and planning iteration free of feature work.
- Letting presentations eat into breakouts leaves teams without a real plan, so cap the morning talks and protect breakout time.
- Treating the confidence vote as a formality hides real doubts, so rework the plan when the average falls below three.
- Leaving dependencies on the board without owners means they slip unseen, so give every red dependency an owner and a date before the event ends.
- Filing the plan away after the event wastes the effort, so update the board after every iteration and report predictability at inspect and adapt.
Frequently asked questions
What is PI planning in SAFe?
It is a regular, face-to-face or remote event where all teams on an Agile Release Train plan the next planning interval together. They align on business goals, plan features across iterations, map dependencies and commit to team objectives. It is often described as the heartbeat of the release train.
How long does PI planning take?
The event usually takes two days for a co-located train. Distributed trains across time zones often spread it over three or four shorter days. Preparation before the event typically takes several weeks.
Who attends PI planning?
All members of the release train's teams attend, along with the release train engineer, product management, business owners, the system architect and shared services. Other stakeholders, such as customer representatives, can join the opening and final reviews. Business owners need to be present for the business value and confidence vote sessions.
What are the outputs of PI planning?
The main outputs are team PI objectives with business value, a program board showing features, milestones and dependencies, a list of program risks addressed with ROAM, and a confidence vote. Teams also leave with iteration plans for the interval.
What is the difference between PI planning and sprint planning?
Sprint planning is a single team planning one iteration of one to four weeks. PI planning brings many teams together to plan several iterations at once, about 8 to 12 weeks, with a focus on dependencies and shared business goals. Teams still run sprint planning inside the planning interval.