Module 7: The Program Increment (PI)

7.1 The Heartbeat of the ART: The Program Increment (PI)

Welcome to Module 7. We’ve talked about the Agile Release Train (ART) as the engine of value delivery. Now, let’s examine the track it runs on and the rhythm that powers its journey. This is the Program Increment (PI), a fixed timebox that acts as the heartbeat for the ART, providing the cadence and synchronization necessary for large-scale development.

A PI is to an Agile Release Train what an Iteration (or Sprint) is to an Agile team. It is a larger, outer loop of the Plan-Do-Check-Adjust (PDCA) cycle, allowing the entire ART to plan, build, validate, and demonstrate a significant increment of value.

Typically, a PI lasts for 8 to 12 weeks, with a 10-week pattern being the most common. This duration is long enough to deliver meaningful, feature-level value but short enough to allow for fast feedback and course correction. A standard PI is composed of a series of development iterations (usually four) followed by one final Innovation and Planning (IP) Iteration.

7.2 The Main Event: A Step-by-Step Guide to PI Planning

The PI begins with its most crucial ceremony: PI Planning. This is an intensive, two-day event where all teams and stakeholders on the ART collaboratively create a shared plan for the upcoming increment. It is the cornerstone event that creates alignment, fosters communication, and builds commitment across the entire train.

The Goal: To align the entire ART to a common mission, define and commit to a set of objectives, and map out the work for the next 8-12 weeks.

The Process: While agendas can vary, a typical two-day PI Planning event follows a structured flow:

Day 1: Understanding the Context and Drafting the Plan

• Business Context & Vision (Morning): The event kicks off with presentations from leadership. A Business Owner or executive outlines the current state of the business and market landscape.  Product Management then presents the product vision and the top 10 features from the ART Backlog.  Finally, the System Architect shares the architecture vision and any technical enablers.
• Planning Context (Morning): The Release Train Engineer (RTE) facilitates the event, explaining the planning process and the desired outcomes.
• Team Breakouts #1 (Afternoon): This is where the real planning happens. Teams gather at their stations (physical or virtual) to:

• Estimate their capacity for each iteration in the PI.
• Analyze the top features and break them down into draft user stories.
• Identify dependencies on other teams and potential risks.
• Create a draft plan, mapping stories into iterations.

• Draft Plan Review (Late Afternoon): Each team presents its draft plan to the entire ART. This is not a formal presentation but a quick summary of their capacity, draft objectives, and key dependencies. The goal is to create transparency and get early feedback
• Management Review & Problem-Solving (End of Day): The RTE facilitates a meeting with management and stakeholders to review the draft plans and address any major scope, dependency, or resource issues that have emerged.

Day 2: Finalizing the Plan and Committing

• Planning Adjustments (Morning): Management communicates any changes or decisions made during the problem-solving meeting. This might include adjustments to scope or priorities.
• Team Breakouts #2 (Morning): Teams return to their breakout sessions to incorporate the adjustments into their plans. During this time, they finalize their PI Objectives and work with Business Owners to assign business value to each one.
• Final Plan Review (Afternoon): Each team presents its final, refined plan to the ART. At this point, the plan is well-understood, and major dependencies and risks have been addressed.
• Program Risks and ROAMing (Afternoon): The entire ART discusses the program-level risks identified during planning. Each risk is categorized using the ROAMing technique: ⁴

• Resolved: The risk has been addressed and is no longer a concern.
• Owned: Someone on the train takes ownership of managing the risk.
• Accepted: The risk is understood and cannot be resolved, so it is accepted.
• Mitigated: A plan is put in place to reduce the likelihood or impact of the risk.

• Confidence Vote (Afternoon): With a final plan in place, the RTE conducts a confidence vote. Using a “fist of five” (1 for no confidence, 5 for high confidence), every team member votes on their confidence in achieving the team’s objectives. If the average is too low (typically below 3), the plan must be reworked.
• Retrospective (End of Event): The RTE leads a brief retrospective on the PI Planning event itself to identify what went well and what can be improved for the next one.

7.3 Defining Success: Crafting PI Objectives

A crucial output of PI Planning is not just a list of features to be completed, but a set of PI Objectives. ¹⁵ These are a summary of the business and technical goals that an Agile Team or the entire ART intends to achieve in the upcoming PI. They are the “why” behind the work and provide a common language for communicating with business stakeholders.

Well-written PI Objectives follow the SMART format:

• Specific: Clearly state the intended outcome.
• Measurable: Define how success will be quantified.
• Achievable: Ensure the objective is realistic for the team.
• Relevant: Align the objective with broader business goals.
• Time-bound: Set a timeframe for achievement within the PI.

During PI Planning, each team writes its own objectives. Then, the Business Owners review these objectives and assign a business value score (typically on a 1-10 scale) to each one, indicating how critical it is to the business.

Committed vs. Uncommitted Objectives:

Teams create two types of objectives:

• Committed Objectives: These are the objectives the team is confident they can deliver within the PI. The team commits to doing everything possible to achieve them.
• Uncommitted Objectives: These are goals the team plans to work on but have lower confidence in delivering, often due to high risk or dependencies. They are not part of the commitment, but they are included in the plan to ensure capacity is understood. ¹⁵ This provides a reliable buffer and improves predictability.

7.4 Visualizing the Plan: Managing Dependencies on the ART Planning Board

The second major output of PI Planning is the ART Planning Board (formerly known as the Program Board). This is a large, physical or digital board that provides a visual summary of the entire plan for the PI.

Structure of the Board:

• Rows: Each row represents a single Agile Team on the ART. There is often a special row at the top for significant milestones.
• Columns: Each column represents an iteration within the Program Increment.

How it’s Used:

During the team breakouts, teams place sticky notes (or digital cards) on the board to represent the features they plan to deliver in each iteration. 20 When a team identifies a dependency — where they need something from another team to complete their work — they use a piece of string (typically red) to connect their feature card to the feature card of the team they depend on.