6.3 Pre- and Post-PI Planning for Large Solutions

6.3 Pre- and Post-PI Planning for Large Solutions

Executive Summary: When an enterprise system exceeds the scope of a single Agile Release Train—such as developing an autonomous aircraft, an integrated medical imaging suite, or a global banking transaction network—enterprises implement Large Solution SAFe. Coordinating multiple ARTs and external suppliers requires a dedicated Solution Train, a higher-level backlog currency called Capabilities, and synchronized Pre- and Post-PI Planning events to ensure enterprise-wide alignment.

---

Scaling Beyond a Single ART: The Large Solution Context

A standard Agile Release Train maxes out at approximately 125 people. Beyond this threshold, social friction and coordination overhead (Dunbar's number) severely degrade Lean-Agile flow. However, many enterprise missions require hundreds or thousands of engineers across hardware, software, regulatory compliance, and supplier ecosystems.

To solve this challenge without resorting to top-down command-and-control, SAFe introduces the Large Solution SAFe configuration. At this level, multiple ARTs and external suppliers are organized into a Solution Train:

• The Solution Train: A long-lived, cross-functional organizational construct that coordinates multiple ARTs and suppliers to deliver world-class solutions.
• Cadence and Synchronization: All ARTs on a Solution Train plan, execute, and inspect on a common, synchronized Planning Interval (PI) cadence.
• Shared Mission: While each ART delivers a specific subsystem or domain (e.g., flight control software, navigation avionics, hydraulic hardware), the Solution Train ensures all subsystems integrate continuously into a unified, operable solution.

---

The Solution Train Leadership Triad

Just as an individual ART is led by a triumvirate of content, technical, and process authorities, the Solution Train establishes an identical leadership pattern operating at enterprise scale:

  +-------------------------------------------------------------------------+
  |                   SOLUTION TRAIN LEADERSHIP TRIAD                       |
  +--------------------+--------------------------------+-------------------+
  | CONTENT AUTHORITY  |      TECHNICAL AUTHORITY       | PROCESS AUTHORITY |
  |                    |                                |                   |
  | Solution           | Solution Architect /           | Solution Train    |
  | Management         | Engineering                    | Engineer (STE)    |
  |                    |                                |                   |
  | • Solution Backlog | • Solution Intent & NFRs       | • Chief SM / RTE  |
  | • Capabilities     | • Architectural Vision across  | • Facilitates Pre |
  | • Vision & Roadmap |   all participating ARTs       |   & Post-PI events|
  +--------------------+--------------------------------+-------------------+

1. Solution Management (Content Authority)

• Role: Represents the collective voice of the customer and enterprise business sponsors at the Solution Train level.
• Key Responsibilities: Owns the Solution Backlog, defines the Solution Vision and Solution Roadmap, and authors high-level Capabilities. Solution Management prioritizes Capabilities using economic criteria (WSJF) and collaborates with Product Managers across all underlying ARTs to guide feature decomposition.

2. Solution Architect / Engineering (Technical Authority)

• Role: Defines the overarching technical, architectural, and design governance across the multi-train ecosystem.
• Key Responsibilities: Owns Solution Intent (the repository of current and intended solution behavior, specifications, and compliance rules), establishes non-functional requirements (NFRs), defines major subsystem interfaces, and oversees cross-train technical enablers.

3. Solution Train Engineer (STE) (Process Authority)

• Role: Operates as the "Chief RTE" for the entire multi-train organization.
• Key Responsibilities: Facilitates Solution Train execution, coaches RTEs in Lean-Agile practices, oversees train-level flow metrics, removes systemic cross-ART impediments, and directly facilitates Pre-PI Planning and Post-PI Planning events.

---

Capabilities vs. Features: Structural Decomposition

A central competency tested on the SAFe POPM exam is understanding work item hierarchy and sizing across framework levels:

$\text{Portfolio Epics} \longrightarrow \text{Solution Capabilities} \longrightarrow \text{ART Features} \longrightarrow \text{Team User Stories}$

What is a Capability?

• Definition: A Capability is a higher-level solution behavior that addresses substantial customer needs. Because of its scale and complexity, a Capability spans multiple ARTs.
• Sizing Rule: A Capability must be sized to fit within a single Planning Interval (PI) at the Solution Train level. If a proposed capability exceeds one PI, it must be decomposed into smaller capabilities.
• Backlog Location: Resides strictly in the Solution Backlog and is authored and prioritized by Solution Management.

The Decomposition Mechanism: Capabilities to Features

During backlog preparation and Pre-PI Planning, Solution Management and Product Managers collaborate to break down Capabilities into Features:

• While a Capability requires contributions from multiple ARTs, a Feature is allocated to a single ART Backlog and is delivered by the teams on that specific train.
• Product Managers on individual ARTs take ownership of those decomposed Features, define their local acceptance criteria, and prioritize them using WSJF within their ART Backlogs.

---

Pre-PI Planning: Establishing Enterprise Alignment

When multiple ARTs must coordinate delivery, allowing each train to plan in complete isolation creates chaotic dependency bottlenecks. To prevent this, the Solution Train convenes Pre-PI Planning prior to the individual ART PI Planning events.

Purpose and Objectives

Pre-PI Planning establishes strategic alignment and sets the overall solution context. It ensures that when individual Product Managers, RTEs, and teams walk into their local PI Planning sessions, they possess a clear, harmonized understanding of enterprise priorities.

Participants and Timing

• Timing: Typically conducted 1 to 2 weeks before individual ART PI Planning sessions, or as the morning opening of a synchronized enterprise planning week.
• Attendees: Solution Management, Solution Architect, STE, Product Managers from all ARTs, RTEs from all ARTs, System Architects, key Supplier representatives, and executive Business Owners.

Inputs and Outputs

• Key Inputs: Solution Vision, top prioritized Capabilities from the Solution Backlog (with WSJF scoring), Solution Roadmap milestones, Solution Intent architectural updates, and external supplier commitments.
• Key Outputs:
  • A clear Solution Context briefing package.
  • Draft Solution PI Objectives.
  • Pre-allocated Capabilities and candidate Features targeted for each specific ART Backlog.
  • Initial cross-ART dependency and capacity expectations.

---

Post-PI Planning: Aggregating Plans and Resolving Conflicts

After all individual ARTs complete their respective 2-day PI Planning events, the Solution Train reconvenes for Post-PI Planning to synthesize results and finalize commitments.

Purpose and Objectives

Post-PI Planning serves as the final integration and validation checkpoint for the Solution Train. It rolls up individual train commitments into a coherent, overarching solution plan.

Key Activities in Post-PI Planning

1. Aggregating Draft ART Plans:
   • RTEs present their train's committed and uncommitted PI Objectives, delivery timelines, and planned milestone dates.
2. Resolving Cross-ART Dependencies and Bottlenecks:
   • Cross-train dependencies that could not be resolved locally during individual ART planning are surfaced. Solution Management and the STE facilitate trade-offs between trains, adjusting delivery sequences or shifting scope between ARTs.
3. Consolidating the Solution Train ROAM Risk Board:
   • Program risks that have multi-train or enterprise-wide implications are escalated to the Solution Train Risk Board and ROAMed in front of executive Business Owners.
4. Finalizing Solution PI Objectives:
   • Solution Management synthesizes the individual ART objectives into Solution PI Objectives, complete with assigned Business Value from enterprise stakeholders.
5. The Solution Train Confidence Vote:
   • Just as individual teams conduct a fist-of-five confidence vote on Day 2 of local planning, the assembled leadership of the Solution Train conducts a Solution Train Confidence Vote. If confidence is low, plans are reworked until a credible commitment is reached.

+-----------------------------------------------------------------------------------+
|              LARGE SOLUTION PI PLANNING SYNCHRONIZATION CADENCE                    |
+-----------------------------------------------------------------------------------+
|  1. PRE-PI PLANNING (Solution Train Level)                                        |
|     • Solution Management presents Vision & prioritized Capabilities              |
|     • Solution Architect outlines technical roadmap & Solution Intent             |
|     • Allocates candidate Features & dependencies to individual ART Backlogs      |
+------------------------------------------+----------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------+
|  2. INDIVIDUAL ART PI PLANNING EVENTS (Local ART Level - Days 1 & 2)              |
|     • ART #1 (Hardware)    • ART #2 (Avionics)    • ART #3 (Ground Software)      |
|     • Teams plan iterations, draft PI Objectives, identify risks & dependencies   |
+------------------------------------------+----------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------+
|  3. POST-PI PLANNING (Solution Train Level)                                       |
|     • Aggregates ART PI Objectives into overall Solution PI Objectives            |
|     • Resolves remaining cross-ART dependencies & architectural conflicts          |
|     • Consolidates & ROAMs Solution-Level Risks                                   |
|     • Conducts Solution Train Confidence Vote                                     |
+-----------------------------------------------------------------------------------+

---

Essential SAFe vs. Large Solution SAFe: Comparative Reference

The table below details how structural governance, backlogs, work items, and ceremonies scale from Essential SAFe to Large Solution SAFe:

---

The POPM Role in Large Solution Environments

For Product Managers and Product Owners operating within Large Solution SAFe, understanding these organizational boundaries is critical for exam success:

• PM Interaction with Solution Management: Product Managers do not author Capabilities independently; they collaborate with Solution Management to decompose Capabilities into Features allocated to their specific ART Backlogs.
• PO Interaction with Solution Intent: Product Owners ensure their teams understand the non-functional requirements (NFRs) and interface specifications maintained in Solution Intent.
• Solution Demo Participation: Product Management participates in the Solution Demo, where Solution Management formally accepts completed Capabilities based on end-to-end integration across all participating ARTs.