SAFe — process and flows

Purpose: Visual and narrative description of SAFe process flows at team, program (ART), and portfolio levels. KS diagram templates for key lifecycle patterns.

Guide · Updated · Source

1. PI lifecycle (program level)

A Program Increment (PI) is the primary planning and delivery cadence in SAFe — typically 8–12 weeks containing 4–5 iterations plus an Innovation & Planning (IP) iteration.

Program Increment lifecycle

How an ART plans, executes, and closes one bounded program-level planning and delivery cadence.

  1. PI lifecycle (program level)Primary SAFe cadence spanning development iterations plus an Innovation and Planning iteration.
  2. StartOpens the PI with cross-team alignment from PI Planning and committed objectives.
  3. Core steps (see walkthrough below)Teams execute iterations, integrate work, and demonstrate progress through the increment.
  4. OutcomeCloses the PI with inspect-and-adapt learning and readiness for the next planning event.

IP iteration

The final iteration in a PI is typically reserved for: - Innovation and exploration (hackathons, spikes) - Infrastructure and tooling improvements - PI-level System Demo and I&A - Preparation for next PI Planning - Training and cross-team knowledge sharing

Teams should not plan feature work into the IP iteration.

2. Iteration flow (team level)

Within each iteration, team-level flow follows standard Scrum/Kanban patterns:

Team iteration flow

How a single team runs Scrum or Kanban work within each PI iteration.

  1. Iteration flow (team level)Team-scoped delivery rhythm nested inside the larger program increment.
  2. StartBegins iteration planning with a committed backlog slice for the timebox.
  3. Core steps (see walkthrough below)Daily execution, refinement, and review against iteration goals.
  4. OutcomeProduces a potentially shippable increment and iteration review outcomes.
  5. Note: SAFe-specific addition:Every iteration culminates in a cross-team System Demo.

SAFe-specific addition: team iterations feed into the System Demo every iteration, ensuring continuous cross-team integration.

3. ART coordination flow

ART coordination lanes

How parallel teams on a release train coordinate delivery handoffs and inspect-and-adapt feedback.

  1. ART coordination flowProgram-level coordination pattern for teams sharing one Agile Release Train.
  2. Lane ADelivery lane where teams execute feature work toward integrated outcomes.
  3. handoffVisible transfer of dependency output to a consuming team or iteration.
  4. shared outcomeIntegrated result demonstrated to the ART and stakeholders.
  5. Lane BImprovement lane for structured review and adaptation across the train.
  6. inspect / adaptReviews progress, risks, and process adjustments at program cadence.
  7. feedbackActionable input that informs the next planning or execution cycle.

4. Portfolio Kanban flow

Epics flow through the portfolio Kanban system before reaching ARTs:

Portfolio epic Kanban flow

How strategic epics are governed from intake through validation before ART implementation.

  1. Portfolio Kanban flowPortfolio-level Kanban governing epics before they consume ART capacity.
  2. StartEpics enter from strategic themes, stakeholders, or team proposals.
  3. Core steps (see walkthrough below)Epics pass funnel, review, analysis, and go or no-go portfolio gates.
  4. OutcomeBenefit hypothesis is validated or invalidated with traceable portfolio decisions.
  5. Note: | Capture epics from strategic themes, stakeholders, teams |Funnel stage captures candidate epics without heavy upfront investment.
Stage Activity
Funnel Capture epics from strategic themes, stakeholders, teams
Reviewing Lightweight evaluation; filter out low-value or duplicate items
Analyzing Develop Lean business case (benefit hypothesis, MVP scope, cost estimate)
Go / No-Go LPM decides based on Lean budget, strategy alignment, capacity
Portfolio Backlog Approved epics awaiting ART capacity
Implementing Epic decomposed into features on ART program backlog
Done Benefit hypothesis validated or invalidated

5. Release on demand

SAFe decouples release from PI cadence. Teams can release at any point when:

  1. Features meet Definition of Done and acceptance criteria
  2. Continuous delivery pipeline is green (build, test, stage)
  3. Business decides to release (business value, market timing)

Release on demand flow

How teams ship value on a cadence independent of PI planning boundaries.

  1. Release on demandDecouples customer-facing release timing from program increment rhythm.
  2. StartA feature reaches Definition of Done with passing acceptance criteria.
  3. Core steps (see walkthrough below)Pipeline builds, tests, and stages before a governed business release decision.
  4. OutcomeValue reaches users without waiting for the next PI boundary.
  5. Note: continuous delivery pipelineSpans build, test, stage, and release readiness across all release activities.

The continuous delivery pipeline spans all four activities. PI cadence provides alignment; release cadence provides value delivery. They need not be the same.

6. Dependency management

Dependencies are first surfaced at PI Planning and tracked throughout the PI:

When How
PI Planning Teams identify dependencies during breakouts; visualized on the program board as strings between teams/iterations
ART Sync RTE and SMs review dependency status; escalate blocked items
Daily Stand-up Teams surface intra-team blockers; cross-team items go to SM → ART Sync
I&A Review dependency-related delays; improve architectural runway to reduce future dependencies

ROAM model for risks identified at PI Planning:

Status Meaning
Resolved Risk no longer exists
Owned Someone accepted responsibility and has a mitigation plan
Accepted Impact understood and accepted; no further action
Mitigated Actions taken to reduce probability or impact

7. References