PI Planning

PI Planning is the single most important event in SAFe. It's where the entire ART—every team, every role—comes together to plan the next Program Increment.

Why is face-to-face planning with 50-125 people worth the investment?

1. Alignment at scale: Everyone hears the same vision, the same priorities, the same constraints. Misalignment that would take weeks to discover and fix is surfaced and resolved in hours.

2. Dependency management: Teams identify dependencies with other teams during planning, not during development when it's too late to adjust. The program board makes dependencies visible at a glance.

3. Collective commitment: Teams commit to objectives they helped define. This isn't top-down assignment—it's collaborative negotiation. People commit more deeply to plans they shaped.

4. Social connection: Humans build trust through face-to-face interaction. Two days of working together builds more trust than months of Slack messages. Trust is the currency that makes cross-team coordination work.

5. Fast problem-solving: When 100+ people are in the same room, problems get solved in minutes that would take days over email. Need to clarify a requirement? Walk ten steps. Need to negotiate a dependency? Have the conversation now.

PI Planning typically happens every 8-12 weeks. The investment is significant (2 days × 100 people = 200 person-days), but the return—in alignment, reduced rework, and faster delivery—consistently justifies the cost.

PI Planning follows a structured two-day format:

Day 1:

• Business Context (1 hour) — Senior leadership presents the current business situation, market dynamics, and strategic priorities. This is the "why" behind the upcoming PI.
• Product/Solution Vision (1 hour) — Product Management presents the top features for the PI, explains priorities, and answers questions. This is the "what."
• Architecture Vision (30 min) — System Architect presents technical direction, architectural runway status, and cross-cutting concerns. This is the "how" at a high level.
• Team Breakouts (3-4 hours) — Teams go to their team areas and plan. They decompose features into stories, identify dependencies, estimate capacity, and draft their PI objectives. This is where the real work happens.
• Draft Plan Review (2 hours) — Each team presents their draft plan (2 minutes per team) to the entire ART. Other teams listen for dependencies and conflicts.

Day 2:

• Planning Adjustments (1-2 hours) — Based on the draft plan review, teams adjust their plans. Dependencies are negotiated. Scope is adjusted. Product Management may reprioritize based on what teams learned.
• Final Plan & Confidence Vote (1 hour) — Each team presents their final PI objectives and the ART votes on confidence. Everyone holds up 1-5 fingers. If average confidence is below 3, the ART discusses and re-plans until confidence improves.
• PI Planning Retrospective (30 min) — Quick retro on the planning event itself. How can we make PI Planning better next time?

The Program Board is a physical (or digital) artifact that makes dependencies visible across teams and iterations.

Structure: A grid with teams as rows and iterations as columns. Teams place feature cards in the iteration where they plan to work on them. Dependency strings (literally colored yarn on a physical board) connect cards between teams.

What the Program Board reveals:

• Which teams are working on which features in which iterations
• Cross-team dependencies (the strings between cards)
• Milestones and delivery commitments
• Potential bottlenecks (too many strings pointing to one team)

Reading the board:

• Red strings = high-risk dependencies (cross-team, hard deadlines)
• Clustering of strings = a team is a bottleneck or single point of failure
• Strings crossing many iterations = long dependency chains that increase risk
• Empty rows = team with unclear objectives (investigate)

The Program Board is one of SAFe's most powerful artifacts because it turns invisible coordination problems into visible, manageable ones. A crowded board with many strings isn't a failure—it's an honest representation of reality that you can now address.

Dependency management strategies:

• Reorder stories to deliver dependencies first
• Pair teams to work on shared components
• Create shared APIs or contracts that decouple teams
• Accept the dependency and manage it with regular sync meetings