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.

The program increment is the largest plan-do-check-adjust (PDCA) learning cycle in SAFe. A PI is to an ART or Solution Train as an iteration is to the Agile team: 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)
  • Aggregate newsworthy value for feedback
  • Assure consistent, Program Level retrospectives

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

The PI cycle is distinct from the release cycle. In some situations, the PI and release cadence are the same, which can be a major convenience. Other programs 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.


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.

The solution train and its 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 Program Increment cadence

The PI represents the outer loop of the Shewart’s PDCA cycle. It aggregates 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):

  • Plan – The PI planning event is the plan step of the cycle.
  • Do – PI execution is the do
  • Check – The System Demo is the check
  • Adjust – The Inspect and Adapt (I&A) is the adjust step

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.

Executing the Program Increment

When it comes to execution, 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 renting a facility, travel, and overhead, and other costs. It also helps the people on the train, especially Business Owners, 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 when, highlighting their dependencies with other Agile teams and trains. PI planning also creates a rhythm for 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, the Agile teams continuously integrate their work and demo it during the Iteration Review and system and Solution Demos.

Scrum of Scrums

The Release Train Engineer (RTE) typically facilitates a weekly (or more frequently, as needed) Scrum of Scrums (SoS) meeting. The SoS continuously coordinates 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 to 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. Sample Scrum of Scrums agenda

Product Owner Sync

In a manner similar to the SoS, a Product Owner (PO) sync meeting is often held for Product Owners 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

The hallmark of each PI is a biweekly system demo 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 the PI 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.

PI Execution for Solution Trains

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 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 agreement on a 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 accumulate 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 the apex 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 demonstrates 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. 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: 20 October, 2017