Planning Interval

A Planning Interval (PI), in SAFe, is a timebox for an Agile Release Train to coordinate work toward shared objectives. The published overview describes eight to twelve weeks as typical, often with four or five development iterations and an Innovation and Planning iteration. The structure is adaptable. An ART is a long-lived group of teams that develops, delivers, and may operate one or more solutions. It is different from a temporary program, although programs may use similar planning practices.

Align plans and expose uncertainty

Joint planning brings objectives, estimates, capacity, and known dependencies into a shared view. Providers and consumers identify what they need, when, and what will establish readiness. Participation can be in person or remote. Record unresolved assumptions, owners, and confirmation dates, including conditions that block dependent work. A planning event can reveal a missing interface agreement; it cannot guarantee discovery of every dependency. Keep updating the plan as new evidence appears.

Separate the planning interval from integration and release

SAFe’s System Demo presents integrated new functionality from the most recent iteration, with a demonstration at each iteration’s end. This supplies feedback within the PI. An additional PI-end review can address broader progress and systemic problems. Teams integrate and validate changes during development rather than waiting for a demonstration. Demonstrating an increment does not mean every planned feature is finished or that all production release conditions have been met.

DORA warns that regrouping small changes for downstream testing or release delays feedback. Plan together on a useful cadence while integrating in small increments and releasing according to readiness and applicable approval. The PI overview allows multiple value increments within an interval and independent team releases where appropriate. A common plan does not require a single release date for everything.

Make decisions when their consequences require them

A fixed planning rhythm need not freeze decisions until its next boundary. Assess changes when they arrive, notify affected owners, and compare urgency, authority, dependencies, and the cost of waiting. Update a local plan within delegation when needed; escalate decisions outside that authority. Changes that can safely wait may be consolidated at the next regular planning event, with the reason and reconsideration triggers recorded. The GOV.UK Service Manual’s emphasis on timely decisions supports this distinction; it does not prescribe waiting for a PI.

In a fictional rail operator’s recovery plan, teams plan every eight weeks, demonstrate integrated increments every two weeks, and integrate changes throughout development. A regulatory reinterpretation in week twenty-six, during the fourth interval, receives an impact review that week rather than waiting for week thirty-two. The sponsor decides an authorized scope change while retaining all required functions. Eleven Green Projects and One Red Program explains the decision, WIP policy, readiness checks, and continuing outcome reviews.

References:

• Scaled Agile, Planning Interval (PI), public definition and overview
• Scaled Agile, Agile Release Train, public definition and overview
• Scaled Agile, System Demo, public definition and overview
• DORA, Working in small batches (CC BY 4.0)
• GOV.UK Service Manual, Governance principles for agile service delivery (Open Government Licence v3.0)