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 Program Increment is to an ART (or Solution Train), as an ‘Iteration is to the Agile Team.It’s a fixed timebox for building and validating a full system increment, demonstrating value, and getting fast feedback. Each PI uses cadence and synchronization to:

  • Facilitate planning
  • Limit Work in Process (WIP)
  • Summarize newsworthy value for feedback
  • Assure consistent, Program Level retrospectives

Due to its scope, the PI provides several observations appropriate for Portfolio Level consideration and ‘roadmapping.’


SAFe divides the development timeline into a set of Iterations within a PI. The Big Picture illustrates how a PI is initiated by a PI Planning session and is then followed by four execution iterations, concluding with one Innovation and Planning 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 the shortest duration.

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’s 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.

The PDCA learning cycle (shown in Figure 1) is represented by the following events in SAFe for the PI (outer loop):

Develop on Cadence. Release on Demand

Continuous execution of PIs provides the rhythm for trains, and the assets they create 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 cadence for the PI can be different from the release cadence. However, in some situations, the PI and release cadences are the same, which can be a major convenience. Other ARTs may need to release less or more frequently than the PI cadence. Still, others will have multiple, independent release cycles for the solution’s various components.

Executing the Program Increment

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

Figure 2. Program execution events

Each program 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 personal calendars to assure 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. PI planning also creates a rhythm for the integration of work and system demos. One outcome of the PI planning is a set of program PI Objectives, detailing what the ART should have ready for integration and demo 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) meeting. The SoS helps coordinate the dependencies of the ARTs and provides visibility into progress and impediments. The RTE, Scrum Masters, and others (where appropriate) meet to review their progress toward milestones, program PI objectives, and internal dependencies among the teams. The meeting is timeboxed for less than 30 minutes and is followed by a ‘meet after’ to solve any problems. A suggested agenda for the SoS meeting is described in Figure 3.

Figure 3. Example SoS agenda

Product Owner Sync

In a manner similar to the SoS, a PO sync meeting is often held for POs and Product Managers. This meeting 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 Product Manager. The purpose is to get visibility into how well the ART is progressing toward meeting the program PI objectives, to discuss problems or opportunities with Feature development, and to assess any scope adjustments. The meeting 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 before the next PI planning meeting.

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

Release Management Meetings

Release management meetings 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, no less than every iteration. And as “integration points control product development” [1], the PI 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 function as an event in Figure 3, in reality, preparing for the upcoming PI is a continuous process, with three primary focus areas:

  • Management alignment and organizational readiness for planning
  • Backlog readiness
  • The actual logistics for the event—facility readiness

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 is followed by a final system demo, a newsworthy event that illustrates all the Features that have been accomplished during the PI. This is usually done as part of the I&A workshop, which is a regular time to reflect, problem-solve, and take on improvement actions needed to increase the velocity, quality, and reliability of the next PI. The result of the workshop is a set of improvement backlog 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

The Large Solution Level has additional important events and activities, which bring a similar focus to the progress of the solution and 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 a set of features that will advance the solution in alignment.

The pre-PI planning event is used to coordinate input (e.g., objectives, key milestones, business context, and Solution Context) for the ART planning sessions. The post-PI planning event is used to integrate the results from individual ART planning sessions into the vision and Roadmap for the Solution Train.

At the end of the post-PI planning meeting, there should be an agreed set of solution PI objectives to be implemented by the end of the PI and demoed at the next solution demo.

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 system. The solution demo is a critical aspect of the PI learning cycle. This high-profile event allows large solution stakeholders, Customers (or their internal proxies), and senior management to view the progress that the solution has made during the past 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 workshop may be required for the large solution level. It follows the same format as the program level I&A. Due to the number of people involved, attendees at the Solution Train I&A cannot include all stakeholders 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: 18 October 2018