PI Planning
PI Planning is the event that opens each Program Increment. All teams in the development value stream participate — typically over two days — to align on business goals, plan their work for the coming PI, identify cross-team dependencies, and surface risks before delivery begins.
It is the single most important synchronization event in the DVS. Done well, it replaces weeks of fragmented coordination with a shared plan that every team has shaped and committed to. Done poorly — or skipped — the PI begins with misaligned priorities, hidden dependencies, and assumptions that only become problems mid-delivery.
Purpose
PI Planning serves four distinct purposes, each of which is difficult to achieve through any other mechanism:
Alignment on business priorities. All teams hear the same business context — the portfolio direction, the DVS roadmap, and the specific features prioritized for the coming PI — at the same time, from the same people. This eliminates the information asymmetry that accumulates when priorities are communicated team by team over weeks.
Dependency identification and resolution. When teams plan in the same room (physical or virtual), cross-team dependencies surface naturally. A team planning a feature discovers that it depends on an API another team owns. The teams negotiate the timing directly, on the spot. Dependencies that go unidentified during planning become blockers during delivery.
Risk visibility. The planning process surfaces risks that would otherwise stay hidden in individual team backlogs. Making risks explicit — and addressing them collectively — before the PI starts is significantly cheaper than discovering them during delivery.
Team ownership of the plan. Teams produce their own iteration plans rather than receiving plans handed down from program management. This is not a formality. Teams that plan their own work make more realistic commitments and take greater ownership of delivering against them.
Who Participates
PI Planning is a whole-DVS event. The composition matters: the right people need to be present for the event to produce a plan that is both strategically aligned and operationally credible.
All delivery teams — every team in the DVS participates, including platform and enabling teams whose work affects delivery team capacity.
Product management — the Product Manager presents the vision and roadmap, prioritizes the feature backlog for the PI, and is available throughout to answer questions and resolve priority conflicts.
Product Owners — participate with their teams in breakout planning, own their team backlog, and negotiate cross-team dependencies directly.
Delivery Value Stream Facilitator (DVF) — owns the event. Prepares the agenda, facilitates the two days, manages time, and ensures outputs are complete.
System and Solution Architect — presents the architectural runway: the technical foundations and capabilities that need to be in place to support delivery. Identifies architectural work that teams need to plan for.
Business stakeholders and owners — participate in presenting context on Day 1 and reviewing draft plans on Day 2. Their presence signals that the plan matters to the business and enables real-time clarification of business intent.
Preparation
PI Planning does not begin on Day 1. The quality of the event is largely determined by the preparation done in the weeks before it.
Feature backlog readiness is the most critical preparation item. Features entering PI Planning should be analyzed, prioritized, and described with enough detail for teams to estimate and plan them. Features that arrive at PI Planning as vague descriptions generate noise and consume planning time in clarification rather than planning.
Vision and roadmap communication should be done in advance where possible. Presenting strategic context for the first time on Day 1 creates cognitive overload. Teams make better plans when they have had time to orient before the event.
Team capacity calculation — each team arrives at PI Planning with a realistic view of their available capacity for the PI, accounting for holidays, known absence, iteration overhead, and any pre-committed work. Plans built against unrealistic capacity produce unrealistic commitments.
Technical prerequisites — the architectural runway for the PI should be confirmed before planning. Teams should not discover during PI Planning that the infrastructure or shared services they need have not been built yet.
The Two-Day Format
PI Planning follows a structured two-day format. The format is not arbitrary — it reflects the sequence of information that teams need to move from context to committed plan.
Day 1 — Context and Draft Plans
The first day establishes shared context and gives teams time to produce initial iteration plans.
Business and product context opens the event. The Product Manager presents the vision: where the DVS is headed, what the current portfolio priorities are, and what the top features for the coming PI are. Business stakeholders may present specific priorities or constraints. The System Architect presents the architectural runway and any significant technical considerations for the PI.
The purpose of this session is to ensure that all teams are planning against the same information. Questions are encouraged and expected — ambiguity in the context will produce ambiguity in the plans.
Team breakouts follow the context session and occupy most of Day 1. Each team, with their Product Owner, works through the prioritized feature backlog and produces a draft iteration plan for each iteration in the PI. Teams identify which features they can commit to, break features into stories, estimate capacity, and surface any dependencies on other teams or on shared services.
During breakouts, the Product Manager, architects, and DVF circulate between teams — answering questions, resolving conflicts, and identifying cross-team issues that need coordination.
Draft plan review closes Day 1. Each team briefly presents their draft plan: what they are committing to for the PI, their capacity utilization, and any risks or impediments they have identified. This is the first view of what the PI plan looks like across all teams.
Day 2 — Finalization and Commitment
The second day refines draft plans, resolves the dependencies and risks surfaced on Day 1, and produces final commitments.
Adjustments and negotiation begin Day 2. Teams revise their plans based on feedback from the Day 1 review and resolve any cross-team dependencies that were identified but not resolved during breakouts. The Program Board — a visual representation of features, team commitments, and dependencies across iterations — is updated to reflect the current state of the plan.
Risk identification and ROAM is a structured session where the risks surfaced during planning are explicitly addressed. Each risk is classified as: Resolved (the team or program has addressed it), Owned (a specific person has taken responsibility for managing it), Accepted (the risk is acknowledged and accepted without specific mitigation), or Mitigated (action has been taken to reduce the risk). Risks that remain unresolved or unowned after ROAM are escalated immediately.
Final plan review gives each team a brief slot to present their final PI commitments — features planned, capacity used, and any remaining risks. This is the record of what the DVS has committed to for the PI.
Confidence vote closes the event. Each participant votes on their confidence in the plan — typically on a scale of 1 to 5. A fist-of-five or similar mechanism makes individual confidence levels visible across the group. Low confidence votes are not failure — they are information. Teams or individuals with low confidence explain why, and the plan is adjusted or risks are acknowledged before the PI begins.
The confidence vote is a health indicator for the planning process itself. Consistently low votes signal that the preparation was insufficient, the features were not ready, or the plan is unrealistic. Consistently high votes, achieved without meaningful discussion, may indicate the planning is not surfacing real risks.
Outputs
PI Planning produces three primary outputs that guide DVS delivery for the entire PI.
PI Objectives — a set of business goals that each team commits to for the PI. PI Objectives are not a list of features or stories. They are outcome-oriented statements of what the team intends to achieve, expressed in terms the business can understand. Each objective is marked as either committed (the team expects to deliver this) or uncommitted (the team will attempt this if capacity allows). PI Objectives aggregate to a program-level view of what the DVS is delivering in the PI.
Program Board — a visual representation of features, iteration-level team commitments, and cross-team dependencies across the PI. The Program Board makes the dependency web of the PI visible in one place and is the primary tool for tracking cross-team coordination throughout the PI.
Risk register — the output of the ROAM session: a documented list of identified risks with their classification and owner. This feeds directly into the coordination work of the PI — risks that are Owned need active management; risks that are Accepted need to be visible to stakeholders.
Common Failure Modes
PI Planning fails in predictable ways. Recognizing these patterns is the first step to avoiding them.
Features not ready. If the feature backlog arriving at PI Planning is not well-defined, teams spend planning time in clarification rather than planning. The event runs long, plans are shallow, and commitments are unreliable. Feature readiness is the single highest-leverage preparation investment.
Business absent. When business stakeholders and product management are not present or not engaged, teams plan in a context vacuum. The confidence vote is meaningless if the people who need to validate the plan are not there to validate it.
Dependency discovery too late. When cross-team breakouts are not structured to surface dependencies explicitly, teams leave PI Planning with hidden dependencies that surface as blockers in mid-PI. The Program Board should be treated as a primary output, not an afterthought.
Overly optimistic capacity. Teams that plan at 100% capacity have no room for the unplanned work, integration problems, and coordination overhead that always materializes during delivery. Sustainable planning uses realistic capacity — typically 70–80% of theoretical maximum — and treats the remainder as a buffer rather than an opportunity to commit more.
Plans not consulted after Day 2. If the PI plan is produced and then ignored, the planning investment is wasted. The program board and PI objectives should be active management tools throughout the PI — not artifacts that live in a document repository.
Scaling Considerations
PI Planning scales to different DVS sizes, but the logistics change as team count grows.
In smaller DVSs with two to four teams, PI Planning can operate as a single group throughout — full-group breakouts and plenary reviews are practical.
In larger DVSs, team breakouts operate in parallel and require explicit coordination mechanisms. The Program Board becomes more important as the dependency surface grows. Cross-team dependency resolution may need dedicated time between Day 1 and Day 2 breakouts.
Distributed and remote PI Planning is achievable with the right tooling — shared digital boards, breakout rooms, and asynchronous preparation take on greater importance. The core structure remains: shared context, team planning, dependency surfacing, collective commitment. What changes is the facilitation mechanics, not the purpose of each session.
The event should be the right size for the DVS — not forced into a template designed for a different scale.