How to Run PI Planning in SAFe, Step by Step

Run a PI Planning event that turns business context into team iteration plans, visible dependencies, named risks and committed PI objectives.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

PI planning is the event where an Agile Release Train (ART) turns direction into a plan it can commit to for the next Program Increment. For background on the framework itself, see the Scaled Agile Framework method page. This page covers the doing: preparing inputs, running breakouts, surfacing dependencies and risks, and closing with objectives the teams actually believe.

The shape of the event comes from SAFe's guidance, where the standard agenda opens with presentations on business context and vision, followed by team planning breakouts in which each team creates iteration plans and objectives for the upcoming PI. That alternation between large-group briefings and small-team breakouts is the core mechanism, because it lets shared context be translated into team-level objectives and iteration plans. Every team hears the same story, then works it through against its own capacity.

The inputs are a vision, a prioritized set of features from the ART backlog, each team's available capacity, and known constraints such as fixed release dates, audits or shared test environments. The outputs are iteration plans per team, PI objectives per team, a visible map of cross-team dependencies, a list of risks with owners or dispositions, and a confidence vote on the whole plan.

The objectives matter well beyond the event. SAFe describes how an ART builds and maintains its Continuous Delivery Pipeline so it can define, build, validate and release functionality that meets its PI objectives. The objectives agreed here become the yardstick for the increment, and they feed the Inspect and Adapt event held at the end of each PI, where the current state of the solution is demonstrated and evaluated. Vague objectives produce a vague review.

SAFe's release train guidance also stresses that the first pipeline stages work together to support deployment of small batches of new functionality, so a good plan breaks features into increments that land across several iterations rather than one large delivery in the final iteration.

Who belongs in the room: every member of every team on the train, product management, business owners who present context and weigh objectives, system architects, and the Release Train Engineer who facilitates. You know the skill is working when teams leave with objectives they can explain in plain business terms, every dependency has a receiving team that agreed to it, and the confidence vote reflects real belief rather than social pressure.

How It Works

The event runs as a loop of broadcast and breakout. Leaders broadcast context to the whole train, teams break out to plan against it, and the results come back to the whole train for review. Each pass narrows uncertainty until the plan is stable enough to vote on.

flowchart TD
  A[Business context briefing] --> B[Vision and top features]
  B --> C[First team breakout]
  C --> D[Draft plans and objectives]
  D --> E[Draft plan review]
  E --> F[Management adjustments]
  F --> G[Second team breakout]
  G --> H[Final plan review]
  H --> I[Risk handling]
  I --> J[Confidence vote]
  J -->|Low confidence| G
  J -->|High confidence| K[Committed PI plan]

Day one opens with the broadcast. SAFe's agenda puts business context and vision presentations first, followed by team planning breakouts. Business owners explain what the organization needs and why now. Product management walks through the top features in priority order. Architects describe technical direction and enabler work that teams must make room for.

The first breakout is where real planning happens. SAFe describes teams in these breakouts working to plan stories into iterations, expose cross-team dependencies, and identify risks and impediments that could affect delivery. Teams size their capacity per iteration, pull features into stories, and place those stories on an iteration grid. Whenever a story needs something from another team, the dependency goes onto a shared board with both teams named. Draft PI objectives are written in business language, not as a list of story titles.

The draft plan review closes day one. Each team presents its draft iteration plan, objectives, dependencies and risks. Leaders then meet without the teams to resolve what the drafts expose: overloaded teams, features that no longer fit, conflicting priorities. Their output is a set of scope and priority adjustments, not a rewritten plan.

Day two opens with those adjustments, then a second breakout where teams rework their plans. Business owners circulate and weigh each team's objectives by business value, which forces a conversation about what truly matters. The final plan review follows, and remaining risks are addressed in front of the whole train. A useful sorting is to mark each risk as resolved, owned by a named person, accepted as is, or mitigated with a stated action.

The confidence vote is the gate. Every team member votes on how confident they are that the train can meet its objectives. If confidence is low, the train returns to a short replanning breakout rather than committing to a plan it does not believe. A plan that passes the vote, with dependencies and risks visible, is the event's deliverable, and it becomes the reference point for delivery through the pipeline during the increment.

Step-by-Step Guide

Step 1: Preparing the planning inputs

Before the event, product management finalizes a prioritized list of features for the ART backlog, and business owners agree on the vision they will present. Each team calculates its capacity per iteration, accounting for holidays, support rotations and known absences. Architects list enabler work the train must make room for, such as infrastructure or compliance changes. Logistics matter as much as content: one room or one virtual space, a shared dependency board, and templates for iteration plans and objectives.

The output is a planning pack every team can read before day one.

Pro tip: Ask each team to pre-read the top features and flag anything unclear, so questions surface before the event rather than during the first breakout.

Step 2: Briefing business context and vision

Open with the whole train together and present business context, then the vision, then the top features in priority order. SAFe places these presentations ahead of the team planning breakouts so every team works from the same picture. Keep each briefing focused on why the work matters and what outcome leaders expect, not on implementation detail. Leave time for questions after each segment, since unasked questions become wrong assumptions in the breakout.

The briefing is done when a team member could explain the top priorities to a colleague who missed it.

Pro tip: Time-box each briefing, for example 30-45 minutes, so teams get enough breakout time to plan properly.

Step 3: Running the first team breakout

Each team moves to its own space with its capacity figures and the prioritized features. Teams split features into stories, estimate them, and place them on an iteration grid until capacity is filled, leaving a buffer for unplanned work. In the same breakout, teams plan stories into iterations, expose cross-team dependencies, and identify risks and impediments. Draft PI objectives are written as short business statements that describe what will be true at the end of the increment.

Product owners and product management stay available to answer scope questions as they arise.

Pro tip: Plan features to land in slices across iterations rather than all in the last one; a plan with everything finishing in the final iteration is a warning sign.

Step 4: Mapping cross-team dependencies

Every dependency goes onto a shared board that shows which team needs what, from whom, and by which iteration. A dependency is only real once the providing team has seen it and agreed to the date; until then it is a request. Teams walk over to each other, or open a shared channel, to negotiate dates in real time. Chains of dependencies that converge in one late iteration signal schedule risk and should be raised in the draft plan review.

The output is a board where every line has two named teams and an agreed iteration.

Pro tip: Use a distinct marker for unconfirmed dependencies so the facilitator can see at a glance which requests still need a conversation.

Step 5: Reviewing draft plans and adjusting scope

At the end of the first breakout, each team presents its draft iteration plan, objectives, dependencies and top risks to the whole train. Keep presentations short and consistent so leaders can compare load across teams. Afterward, leaders meet separately to resolve what the drafts reveal: overcommitted teams, features that no longer fit, or priorities that conflict. They produce scope and priority adjustments that are announced to the train when planning resumes.

Their job is to change constraints, not to rewrite team plans.

Step 6: Finalizing PI objectives and risks

In the second breakout, teams rework plans against the adjustments and finalize their PI objectives. Business owners visit each team and weigh each objective by business value, which exposes mismatches between what a team thinks matters and what the business needs. Objectives that depend on uncertain work can be marked as stretch rather than committed, so the plan stays honest. Remaining risks are brought to the whole train and each is given a clear disposition and owner.

The output is a final plan per team with weighted objectives and no orphaned risks.

Pro tip: Rewrite any objective that reads like a story title into a statement of business outcome, for example 'customers can pay by invoice' instead of 'build invoice API'.

Step 7: Holding the confidence vote

Ask every team member to vote on their confidence that the train will meet its committed objectives, using a simple scale such as a show of fingers. Voting happens openly and quickly so the result reflects instinct rather than deliberation. If confidence is low, ask the low voters what worries them and address it, then run a short replanning session. Only commit the plan once confidence is genuinely acceptable across the train.

Close with a brief retrospective on the event itself so the next PI planning runs better.

Pro tip: Treat a low vote as useful information, not a failure; forcing a revote without changing anything teaches teams to hide doubt.

Best Practices

• Present business context before features. When teams understand why the work matters, they make better trade-offs in the breakout and write objectives that reflect outcomes instead of tasks.
• Plan against measured capacity, not hope. Teams that fill every iteration to the brim have no room for defects or support work, and the plan starts slipping in the first iteration.
• Make every dependency a two-sided agreement. A dependency the providing team never acknowledged is the most common source of mid-increment surprises, so require both team names and an agreed iteration on the board.
• Keep leaders in the constraint-setting role. Management review should change scope, priorities or resources, then hand planning back to teams; leaders who rewrite team plans destroy the ownership that makes the commitment credible.
• Distinguish committed from stretch objectives. Marking uncertain work as stretch keeps the plan honest and gives Inspect and Adapt a fair basis for measuring predictability.
• Slice features to deliver across iterations. SAFe's guidance on pipeline stages supporting small batches of new functionality means a plan should show value landing incrementally, which also shortens feedback loops.
• Run the event as a loop, not a lecture. The alternation of briefings and breakouts that SAFe describes exists so shared context becomes team-level objectives and iteration plans; cutting breakout time to fit more presentations defeats that purpose.

Common Mistakes

• Treating PI planning as a top-down announcement where leaders hand teams a finished plan.: Leaders provide context and priorities, then teams build the plan in breakouts. A plan teams did not create will not survive the first unexpected problem.
• Writing PI objectives as lists of stories or features.: Objectives should state business outcomes a stakeholder can recognize. Story lists belong in iteration plans; objectives are what business owners weigh and what Inspect and Adapt evaluates.
• Leaving dependencies and risks in team notes instead of on a shared board.: SAFe expects breakouts to expose cross-team dependencies and identify risks and impediments, and exposure means visible to the whole train. Put every dependency and risk where the facilitator and other teams can see it.
• Stacking all feature completion into the final iteration.: This hides integration risk until it is too late to react. Break features into slices that complete across iterations so problems surface early.
• Pressuring teams into a high confidence vote.: A coerced vote hides the very doubts the vote exists to surface. When confidence is low, listen to the reasons, adjust scope, and replan before committing.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Scaled Agile Framework

Related Skills

• Managing a Lean Portfolio in SAFe
• Splitting Features into User Stories and Enablers
• Launching and Running Agile Release Trains
• Running Inspect and Adapt Workshops
• Implementing the SAFe Continuous Delivery Pipeline
• Coordinating Multiple ARTs with Solution Trains
• Prioritizing Work Using WSJF

Sources

• Planning Interval (PI) - Scaled Agile Framework
• SAFe Glossary
• Agile Release Train - Scaled Agile Framework

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.