Doing is a quantum leap from imagining.
A Program Increment (PI) is a timebox in which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically eight to twelve weeks long, and the most common pattern for a PI is four development iterations, followed by one Innovation and Planning (IP) iteration.
The Program Increment (PI) is the largest plan-do-check-adjust (PDCA) learning cycle in SAFe. A PI is to the Agile Release Train or Solution Train as an Iteration is to the Agile Team: a cadence-based interval for building and validating a full system increment, demonstrating value and getting fast feedback. Each PI is a development timebox that uses cadence and synchronization to facilitate planning, limit Work in Process (WIP), provide for aggregation of newsworthy value for feedback, and assure consistent, program-level retrospectives. Due to its scope, the PI timebox also provides the right level of thinking for Portfolio Level consideration and roadmap.
(The PI aggregates multiple teams—and multiple iterations of work—into an amount of value and a timebox that the Enterprise can focus on. And while continuous integration and system/solution validation is always the goal, the PI timebox can also provide a forcing function for full system integration and validation. This can significantly reduce the risk of deferred integration and, even worse, deferred or slow internal or external customer feedback. (move this paragraph to to details.)
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 Program Increment (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 that a PI duration of between 8 and 12 weeks works best, with a bias toward the shortest duration.
The PI is the outer-loop cadence of the PDCA cycle; it aggregates a strategic unit of time and value into a meaningful point to objectively measure the Solution under development. And as “integration points control product development” , the PI is the routine point at which the meaningful emergent behavior of the full system or solution can be evaluated.
The Solution Train and its Agile Release Trains (ARTs) use the same PI cadence, as Figure 1 illustrates.
The PI follows a classic PDCA learning cycle. PI planning is the “plan” step of the cycle, and the “do” step is the PI execution, the “check” is the demo, and the Inspect and Adapt workshop represents the “adjust.” This applies to both the value stream and the ARTs, as can be seen in Coordination.
Develop on Cadence, Release on Demand
Continuous end-to-end sequencing of PIs is the metronome of the Agile Release Train. ART assets grow continuously and incrementally. Releasing solutions, however, is a separate concern, which is covered in the Release on Demand article. With these principles, programs and/or value streams are free to establish the best product development rhythm, continuously building incremental functionality. The business is free to deploy releases as and when the business or 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. Each program event is described in the sections below.
Each PI begins with a PI Planning session. Given the fixed cadence and routine nature of these critical events, dates can be fixed and scheduled well (often up to a year) in advance. This lowers facility, travel, overhead, and other transaction costs.
During PI planning, the teams estimate what will be delivered and when, and highlight their interdependencies. PI planning also creates the baseline for the integration and demo pull events by defining what will be built and demonstrated. One outcome of the PI planning is a set of program PI Objectives, detailing what the ART will have ready for integration and demo at the end of the PI.
Scrum of Scrums
The Release Train Engineer (RTE) typically facilitates a weekly (or more frequently, as conditions require) Scrum of Scrums (SoS) meeting to continuously coordinate dependencies of the Agile Release Train and to provide visibility into progress and impediments. The RTE, Scrum Masters, and others (where appropriate) meet to update 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 problems identified. A suggested agenda for the SoS meeting is described in Figure 3.
In a manner similar to the SoS, a PO Sync meeting is often held for Product Owners and Product Managers. This meeting typically occurs weekly, or more frequently as conditions require. The PO Sync is also timeboxed (30 to 60 minutes) and is followed by a “meet-after” to solve problems identified during the meeting.
This meeting may be facilitated by the RTE or Product Manager. The purpose of the meeting 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, WSJF prioritization prior to the next PI planning meeting, and more.
Note: As illustrated in Figure 2, sometimes the Scrum of Scrums and PO Sync are combined into one meeting, often referred to as an ART sync.
Release Management Meetings
Release Management provide governance for any upcoming releases and also provide regular communication to management. To learn more read the Release on Demand article.
The hallmark of each PI is a biweekly System Demo. The demo is used to get feedback from the stakeholders about the efficacy 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 and no less than every iteration.
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—an actual, specific, and committed PI plan—careful consideration of all three factors is warranted.
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 inspect and adapt (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 stories that can be added to the backlog for the upcoming PI planning. In this way, every ART improves every PI.
PI Execution for Large Solutions
The Large Solution level has additional events and activities necessary to bring a similar focus to the progress of the solution. These are described next.
Pre- and Post-PI Planning
The Pre- and Post-PI Planning meetings allow Agile Release Trains and Suppliers in large value streams to build an aligned plan for the next program increment. The pre- and post-PI planning meetings serve as a wrapper for the PI planning meetings at the Program Level, which is where the actual, detailed planning takes place, as can be seen in the IP iteration calendar (see Innovation and Planning Iteration).
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 is a high-profile event where value stream stakeholders, Customers (or their internal proxies), and senior management view the progress that the solution has made during the past program increment.
At this event, the Solution Train demonstrates its accomplishments in the past PI. Senior managers and stakeholders review the progress in the broader solution context. It may also inform decisions about continuation, adjustment, or even cancellation of initiatives, as well as changes to Lean Budgets for the various value streams.
Solution Train Inspect and Adapt
In larger value streams, an additional I&A workshop may be required, following the same format as the Program level. Attendees at that large solution I&A cannot include all stakeholders from the ARTs, so representatives are selected that are best suited to address that context. This includes the primary stakeholders of the large solution level, as well as representatives from the various ARTs and Suppliers.
Learn More Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
Last update: 2 June, 2017