Unless commitment is made, there are only promises and hopes; but no plans.
—Peter F. Drucker
Planning Interval (PI)
A Planning Interval (PI) is a cadence-based timebox in which Agile Release Trains deliver continuous value to customers in alignment with PI Objectives.
PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration. The PI is for an ART like an Iteration is for Agile Teams. It’s a fixed timebox for planning, building, validating, delivering value, and getting fast feedback.
During the PI, Agile Teams apply cadence and synchronization to combine the work of multiple teams into one or more releasable increments. Individual teams may also release value independently, depending on context. The cadence and synchronization of the PI enable the ART to:
- Plan the ART’s next increment of work
- Limit work in process (WIP)
- Summarize newsworthy value for feedback
- Ensure consistent ART retrospectives
Due to its broad scope, the PI provides an appropriate timebox for Portfolio considerations and road mapping.
Details
SAFe divides the development timeline into a series of iterations within a PI. The Big Picture illustrates how a PI begins with a PI Planning event and is followed by four execution iterations, concluding with one IP iteration (Figure 1).
This pattern is suggestive but arbitrary, and there is no fixed rule for how many iterations are in a PI. However, experience has shown that a PI duration between 8 and 12 weeks works best, with a bias toward shorter durations. Organizations implementing Lean Portfolio Management (LPM) often find it beneficial to match the schedule of the Strategy Portfolio Review and Participatory Budgeting events to improve the alignment of strategy with execution. (Please read the events section in the LPM competency article for more information.)
Develop on Cadence
PIs provide the development rhythm for trains and the assets they build to grow iteratively and incrementally. ‘Develop on cadence’ is a label for a coordinated set of practices that support Agile Teams by offering a reliable series of events and activities on a regular, predictable schedule. However, the planning cadence is often different from the release cadence. This approach helps customer-centric enterprises create a continuous value flow for their customers.
The business determines the timing of releases depending on market and customer needs and the organization’s motivation to provide value. Some enterprises frequently release during the PI, while others may be constrained by compliance, supplier dependencies, or other business and market requirements, driving less frequent releases. Decoupling the development events and activities that support value creation from how and when that value is delivered further promotes Business Agility.
ART Events Drive Development
When it comes to execution for a single ART, a dual Plan-Do-Check-Adjust (PDCA) sequence of events creates a closed-loop system to keep the train on the tracks, as illustrated in Figure 2. The outer loop represents the ART’s PDCA cycle for the PI, while the inner circle represents an Agile Team’s PDCA cycle for an iteration. In this example, the team is using Scrum for the inner loop. The diagonal line (PI Start) shows that after ART completes PI Planning, the teams on the train start the inner PDCA loop.
The following sections describe each ART event. The SAFe Scrum article offers guidance for the iteration events shown in Figure 2, and SAFe Team Kanban describes the cycle for the inner loop when using this method.
Plan the PI
Each ART PI begins with a PI Planning event. During this event, the teams estimate what will be delivered and highlight their dependencies with other Agile Teams and trains. One primary outcome of PI planning is a set of PI Objectives detailing what the ART should have to demo at the end of the PI. Moreover, Agile Teams continuously integrate their work throughout the PI and demo functionality during the Iteration Review and System Demos.
PI Planning has a standard agenda that includes a presentation of business context and vision, followed by team planning breakouts—where each team creates its Iteration plans and objectives for the upcoming PI. Facilitated by the Release Train Engineer (RTE), PI planning includes all members of the ART and occurs within the Innovation and Planning (IP) Iteration.
Conduct System Demos
The system demo event tests and evaluates the solution in a production-like environment (often staging) to receive feedback from stakeholders, including Business Owners, executive sponsors, other Agile Teams, development management, and customers (or their proxies). This stakeholder feedback is critical, as only they can evaluate the effectiveness and usability of the solution under development and offer the guidance the ART needs to stay on course or adjust. The system demo event occurs at the end of every Iteration, providing an integrated, comprehensive view of the new Features delivered by the ART.
Inspect and Adapt
Each PI concludes with an Inspect and Adapt (I&A) event, a regular time to reflect, apply problem-solving techniques, and identify improvement actions needed to increase the following PI’s velocity, quality, and reliability. During the I&A, Product Management or other team members showcase all the finished features during the final PI system demo. Quantitative and qualitative measurements and a retrospective problem-solving workshop follow the demo. The result of the I&A is a set of improvement features or stories that the RTE or teams can add to the backlog for the upcoming PI planning. In this way, every ART improves every PI, including course corrections to the solution.
Iterations Drive ART Cadence
All Agile Teams contribute to the ART’s Iterations. However, the specifics of planning and execution during the iteration may differ based on whether the team works in Scrum or Kanban. Those who apply Team Kanban typically work in a continuous flow model, contributing to the ART’s increment during each iteration.
Since Agile teams operate as part of an ART, their cooperation is critical for meeting the agreed-to Team and ART PI Objectives. Accomplishing this collaboration requires teams to align to the same iteration cadence and duration.
Deliver Continuously and Release on Demand
Building and maintaining a Continuous Delivery Pipeline (CDP) allows each ART to define, build, validate, and release new functionality to meet their PI objectives. Multiple Agile teams on the ART share the same CDP as they collaborate within iterations throughout the PI. Each aspect of the CDP is described below:
Note: For some ARTs, continuous delivery means releasing multiple times per day. For others, ‘continuous’ means releasing weekly or monthly—or whatever cycle satisfies market demands and the goals of the enterprise.
Continuous Exploration (CE)
Continuous Exploration focuses on creating alignment on what needs to be built. In CE, design thinking ensures the enterprise understands the market problem, customer needs, and the solution required to meet that need. It starts with an idea or a hypothesis of something that will provide value to customers, typically in response to customer feedback or market research. The concept is further analyzed and researched to understand the requirements for a Minimum Marketable Feature (MMF) or Minimum Viable Product (MVP). Finally, convergence occurs by understanding which features will likely meet customer and market needs.
Continuous Integration (CI)
Continuous Integration focuses on taking features from the ART backlog, applying design thinking tools in the problem space to refine features, conducting user research, and collecting feedback. After they are clearly understood, Agile Teams implement them. Completed work is committed to version control, built and integrated into a system or solution increment, and tested end-to-end before validating it in a staging environment.
Continuous Deployment (CD)
Continuous Deployment takes the changes from the staging environment and deploys them to production. At that point, they’re verified and monitored to ensure they are working correctly. This step makes the features available in production, where the business determines the appropriate time to release them to customers. This aspect allows the organization to respond, roll back, or fix forward.
Release on Demand (RoD)
Release on Demand makes value available to customers all at once or incrementally based on market and business needs. RoD allows the business to release when market timing is optimal and carefully manages the risk associated with each release.
Manage Flow, Scope, Risk, and Dependencies
When viewed as a whole, continuous delivery is an extensive process. Indeed, it may be the most vital capability of every ART. Stakeholders need to visualize and track the ongoing work, even when a significant portion of the pipeline is automated. The ART requires establishing WIP limits to improve throughput and identify and address bottlenecks. That’s the role of the ART Kanban. In addition, Kanban sync events manage flow, scope, risk, and dependencies, as described in the following sections.
Visualize and Limit WIP with the ART Kanban
The RTE, Product Management, and others use the ART Kanban to visualize, track and manage the flow of features from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline. Figure 3 illustrates a typical ART Kanban with example policies governing the entry and exit of features in each process state. It helps the ART improve flow by matching demand to capacity, applying WIP limits, visualizing bottlenecks, and identifying opportunities for relentless improvement. Product Management reviews the Kanban and pulls in more work, respecting WIP limits in collaboration with Product Owners. This Kanban also facilitates reviewing and prioritizing new features based on continuous exploration and offering the information needed to make release and deployment decisions.
Sync on Scope, Progress, and Dependencies
Three sync events help the ART stay on track, as illustrated in Figure 4. The Coach Sync focuses on executing the current PI, including risk, dependencies, progress, and impediments. The PO Sync manages the PI’s scope, reviews progress, adjusts priorities, and prepares for the following PI. Since Product Owners and Scrum Masters/Team Coaches are often interested in similar topics and need to collaborate, sometimes it’s helpful to combine the Coach Sync and PO Sync into a single event known as an ART Sync. The ART Sync usually replaces the Coach Sync and PO Sync for a particular iteration to reduce overhead.
Address Risks with the ROAM Board
The ROAM board created during PI planning (Figure 5) can be reviewed during the ART Sync to ensure those responsible for owning or mitigating a risk take the necessary actions. The ART may also record any new items that may have arisen after planning and ROAM them.
Resolve Dependencies with the ART Planning Board
During the sync events, the RTE, Product Management, Scrum Masters/Team Coaches, and other stakeholders can use the ART Planning Board, shown in Figure 6, to track and manage dependencies, ensuring they do not block other teams.
The ART planning board should be used during and after PI planning to help identify ways to reduce or eliminate dependencies, enabling teams to work more independently and increase value flow.
Last update: 7 February 2023