Doing is a quantum leap from imagining.

—Barbara Sher

Program Increment

A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. 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.

A PI  is to an Agile Release Train (ART) (or Solution Train), as an Iteration is to the Agile Team. It’s a fixed timebox for planning, building, and validating a full system increment, demonstrating value, and getting fast feedback. Each PI applies cadence and synchronization to:

  • Plan the ART’s next increment of work
  • Limit work in process (WIP)
  • Summarize newsworthy value for feedback
  • Assure consistent, ART wide retrospectives

Due to its scope, the PI provides an appropriate timebox for Portfolio Level considerations and ‘roadmapping.’

Details

SAFe divides the development timeline into a series of iterations within a PI. The Big Picture illustrates how a PI is initiated by a PI Planning event and is then followed by four execution iterations, concluding with one IP iteration. This pattern is suggestive but arbitrary, and there is no fixed rule for how many iterations are in a PI. Experience has shown, however, that a PI duration between 8 and 12 weeks works best, with a bias toward shorter durations.

A Solution Train and its associated Agile Release Trains use the same PI cadence, as shown in Figure 1.

Figure 1. The Solution Train and Agile Release Trains follow the same PI cadence

The PI represents the outer loop of the Shewhart PDCA cycle as shown at the top of Figure 1. It combines the value developed by each Agile team into a meaningful Milestone to objectively measure the Solution under development.

This PI (outer loop) PDCA learning cycle is represented in SAFe by the following ART events and activities:

Develop on Cadence, Release on Demand

Continuous execution of PIs provides the rhythm for trains, and the assets they create to grow iteratively and incrementally. Releasing solutions, however, is a separate concern, which is covered in the Release on Demand article. While trains determine the best product development rhythm, the business is enabled to deploy releases whenever it, or the market, requires.

The planning cadence is often different from the release cadence. However, in some situations, the PI and release cadences are the same, particularly in large supply chains (see the supply chains discussion in Enterprise Solution Delivery). Some ARTs may need to release more or less frequently than the PI cadence. Still, others will have multiple, independent release cycles for the solution’s various components.

Executing the PI

When it comes to PI execution for a single ART, a sequence of events creates a closed-loop system to keep the train on the tracks, as illustrated in Figure 2.

Figure 2. ART events

Each event is described in the next sections.

PI Planning

Each PI begins with a PI planning event. Since PI planning occurs on a fixed cadence, the entire calendar year of events can be scheduled well in advance. By scheduling PI planning events in advance, the Enterprise can lower the cost of travel and logistics. It also helps people on the train, especially Business Owners, to manage their other commitments to ensure they can be present for these critical events.

During PI planning, the teams estimate what will be delivered and highlight their dependencies with other Agile teams and trains. One outcome of the PI planning is a set of PI Objectives, detailing what the ART should have ready to demonstrate at the end of the PI. Of course, Agile teams continuously integrate their work and demo it during the Iteration Review and System Demo (or Solution Demo for Solution Trains)

Scrum of Scrums

The Release Train Engineer (RTE) typically facilitates a weekly (or more frequently, as needed) Scrum of Scrums (SoS) event. The SoS helps coordinate the dependencies of the ARTs and provides visibility into progress and impediments. The RTE, representatives from each team (often the Scrum Master), and others (where appropriate) meet to review their progress toward milestones and PI objectives, and dependencies among the teams. The event is timeboxed for 30-60 minutes and is followed by a ‘meet after’ where individuals who want to do a deeper dive into specific problems can remain behind. A suggested agenda for the SoS event is shown in Figure 3.

Figure 3. Example SoS agenda
Figure 3. Example SoS agenda

PO Sync

In a manner similar to the SoS, a PO sync is often held for Product Owners and Product Management. This event typically occurs weekly, or more frequently, as needed. The PO sync is also timeboxed (30 – 60 minutes) and is followed by a meet after to solve any problems.

The PO sync may be facilitated by the RTE or a Product Manager. The purpose is to get visibility into how well the ART is progressing toward meeting its PI objectives, to discuss problems or opportunities with Feature development, and to assess any scope adjustments. The event may also be used to prepare for the next PI (see below) and may include Program Backlog refinement and Weighted Shortest Job First (WSJF) prioritization ahead of the next PI planning event.

(Note: As illustrated in Figure 2, sometimes the SoS and PO sync are combined into one event, referred to as an ART sync.)

Release Management Meetings

Release management events provide governance for any upcoming releases, as well as communication to management. To learn more, read the Release on Demand article.

System Demo

A system demo is a biweekly event that provides feedback from the stakeholders about the effectiveness and usability of the system under development. This demo also helps ensure that integration between teams on the same ART occurs on a regular basis—at least once every iteration. And as “integration points control product development” [1], the system demo is the routine point at which the meaningful, emergent behavior of the full system or solution can be evaluated.

Prepare for the Next PI Planning Event

While we note this activity as an event in Figure 2, in reality, preparing for the upcoming PI is a continuous process, with three primary focus areas:

  • Management alignment and organizational readiness for planning
  • Backlog and content readiness
  • Facility readiness—the actual logistics for the event

Since any one of these can interfere with the potential outcome—a specific and committed PI plan—careful consideration of all three factors is necessary.

Inspect and Adapt

The PI is done when its timebox expires. Each PI concludes with a final system demo called a PI System Demo. This is a newsworthy event that illustrates all the features that have been accomplished during the PI. This is done as part of the I&A event, which is a regular time to reflect, apply problem-solving techniques, and take on improvement actions needed to increase the velocity, quality, and reliability of the next PI. The result of the I&A event is a set of improvement features or Stories that can be added to the backlog for the upcoming PI planning. In this way, every ART improves every PI.

Solution Train PI Execution

Solution Trains have additional important events and activities, which bring a similar focus to the successful development and delivery of large, enterprise solutions. These are described next.

Pre- and Post-PI Planning

Pre- and Post-PI Planning events are used for preparation and coordination of PI planning across multiple ARTs and Suppliers in a Solution Train. The purpose of these events is to create a common Vision and mission, and align around a set of features and Capabilities that will advance the solution.

The pre-PI planning event is used to coordinate inputs (e.g., business context, key milestones and Solution Context) for the individual ART PI planning events. The post-PI planning event is used to integrate the results from each ART PI planning event, manage identified risks and dependencies, and update the Roadmap for the Solution Train.

At the end of the post-PI planning event, there should be a commitment to an agreed set of solution-level PI objectives to be implemented by the end of the PI.

Solution Increment and Solution Demo

During the PI timebox, the ARTs build multiple increments of value, which grow into solution capabilities. The new capabilities must be designed, developed, tested, and validated holistically, along with the existing capabilities of the solution. The solution demo is a critical aspect of the PI learning cycle for a Solution Train. This high-profile event allows large solution stakeholders, customers (or their internal proxies), and senior management to view the progress that the Solution Train has made during the PI.

At this event, the Solution Train demos its accomplishments for the entire PI. Senior managers and stakeholders review the progress in the broader solution context. It may also inform decisions about whether to pivot or persevere with capabilities, as well as changes to Lean Budgets for the various Value Streams.

Solution Train Inspect and Adapt

At the end of the PI, an additional I&A event may be required at the Large Solution Level. It follows the same format as the I&A for the ART. Due to the number of people involved, attendees at the Solution Train I&A cannot include everyone from the ARTs, so the best-suited representatives are selected to address that context. This includes the primary stakeholders of the Solution Train, as well as representatives from the various ARTs and suppliers.

Learn More

[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

 

Last update: 6 September 2022

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.