Flow Metrics for PI Execution

Moving ART Sync from Status Reporting to Flow Control

Most Agile Release Trains begin PI execution with the right intentions—and the wrong signals.

After PI Planning, we typically have:

An ART Planning Board showing a feature delivery timeline
PI Objectives summarizing intended business outcomes
Success measured by plan adherence

Then execution begins… and ART Sync quietly devolves into PM-style status reporting:

“Feature X is 60% done”
“Team Y is on track”
“We think we’ll make it”

This is familiar.
It is also largely ineffective.

This post outlines an alternative: using flow metrics—WIP and aging—as the primary signals for managing delivery risk for PI execution, supported by a simple Kanban system and a re-shaped ART Sync. Topics include:

Flow metrics as the execution control system
Feature-level Kanban to support PI execution
WIP + aging as primary signals
ART Sync reshaped around exceptions
Feature sizing to optimize flow (≈2-sprint features)
Clear separation of development flow vs release flow
Planning Board demoted to context, not control

Why Status Reporting Fails at Scale

Status-based execution management has predictable failure modes:

Percent-complete hides waiting and blocked time
Risks surface late, when options are limited
Meetings get longer without improving outcomes
Teams optimize reporting instead of flow

Most importantly, status tells us nothing about delay risk.

Flow metrics do.

A Core Reframe: Execution Is About Flow, Not the Plan

PI Planning produces a hypothesis:

What we believe is important
How we believe value will flow
Where we think dependencies exist

During execution, the question is no longer: “Are we on the plan?”

It is: “Is value flowing as expected, and where is risk accumulating?”

Plans are static.
Flow is empirical.

Why Status Reporting Fails at Scale

Status-based execution management has several well-known failure modes:

Percent-complete hides waiting and blocked time
Problems surface late, when options are limited
Meetings grow longer without improving outcomes
Teams optimize reporting instead of flow

Most importantly, status tells us nothing about delay risk.

Flow metrics do.

The Minimum Kanban System Needed for PI Execution

To manage flow during a PI, the ART needs a shared Kanban view at the feature level. Not for planning—but for execution.

A minimal, effective workflow looks like this:

ART Backlog

│

▼

Ready

│  (pull)

▼

In Implementation

│

├──► Blocked / Waiting

│         │

│         └──► back to In Implementation

│

▼

Development Done (Ready for Release)

│

▼

Done (Released/Deployed)

State Definitions:

In Implementation
Feature has been pulled by teams and is actively being developed. Feature aging starts here.
Ready for Release (Development Done)
Feature is fully implemented, integrated, tested, and accepted. Can be released on demand. Feature aging stops here.
Done (Released). Production release timing is tracked separately.

Feature age is time from In Implementation to Development Done.

What “Done” Means for Feature Aging

For the purposes of PI execution and ART Sync, feature age is measured from the moment a feature enters “In Implementation” until it reaches “Ready for Release.” In this context, Done does not mean released to production. It means the feature is development-complete: integrated, tested, accepted, and deployable on demand. In organizations that practice develop on cadence, release on demand, release timing is intentionally decoupled from development flow and is therefore tracked separately. Feature aging exists to manage development flow and execution risk, not downstream release scheduling.

In ART execution, “Done” means ready to release, not released.

ART Sync manages development flow
Aging is a leading indicator of execution risk

Key Design Principles

Aging starts when a feature enters “In Implementation”
Features do not age while waiting in the backlog
Blocked / Waiting is explicit (not hidden in comments)
WIP limits apply to “In Implementation”

This workflow exists to make flow visible, not to micromanage teams.

The Flow Metrics That Matter During the PI

During execution, most metrics are noise. A few are decisive.

1. Feature Implementation WIP (ART-Level)

What it tells you:
How much work is in progress across the ART.

Too much WIP:

Increases queues
Delays feedback
Makes everything late at once

Actions/Decisions:

Stop starting
Start finishing

2. Feature Aging (Leading Indicator)

Feature aging is measured as: Time from entry into “In Implementation” until “Done”

What it tells you:
Where risk is accumulating right now.

A practical guideline:

Features should ideally complete in ~2 sprints
Aging beyond ~3 sprints deserves attention
Features expected to span most of a PI (> ~4 sprints) should be explicitly flagged as flow risks during PI Planning

Aging is not a performance metric.
It is an early warning system.

Why Small (≈2-Sprint) Features Matter

To make flow metrics meaningful, features must be small enough for aging to expose risk early.

In practice, this means shaping features so they normally complete in roughly two sprints.

Features of this size preserve critical options:

They can finish early
They can be re-sequenced if priorities change
They can be stopped if learning indicates diminishing returns

As features grow larger and span most of a PI, those options disappear. Long-running features collapse delay-risk mitigation into a single outcome at the end of the PI—when it is too late to act.

Small features do not guarantee faster delivery.
They dramatically improve our ability to manage risk through flow, which is the real objective during PI execution.

3. Blocked / Waiting Time

What it tells you:
Why aging is happening.

Blocked time reveals:

Dependency issues
Decision latency
Environment or integration problems
Organizational friction

This shifts ART conversations from: “Why are we late?”

To: “What is preventing flow?”

4. Throughput (Context, Not Control)

What it tells you:
What the system can actually deliver.

Throughput supports:

Empirical forecasting
Early expectation management
Honest mid-PI conversations

It should not be used to pressure teams.

Re-Shaping ART Sync Around Flow

With these signals in place, ART Sync can change fundamentally.

Traditional ART Sync Agenda

Feature-by-feature status
Progress against plan
Dependency check-ins
Long, unfocused discussions

Flow-Based ART Sync Agenda (One Page)

The agenda is driven by exceptions, not by the plan.

Features aging beyond threshold – ranked list of in-progress features with their current ages
Blocked features called out
WIP limit breaches
Any material change in priority or risk

The purpose of this slide is not reporting—it is filtering.

Only items above threshold deserve airtime.

Below-threshold work is assumed healthy.

This mirrors how well-run teams use aging in daily standups—just at a higher altitude.

What Happens to the ART Planning Board?

The planning board does not disappear.

During execution, it becomes:

A context artifact
A dependency hypothesis
A reminder of original intent

It is consulted when:

Reality diverges materially from expectations
Dependencies surface unexpectedly
Flow metrics indicate elevated risk

It is no longer used as a control mechanism.

Why This Works Better

Using flow metrics for PI execution:

Surfaces risk early
Keeps meetings short and purposeful
Reduces late-PI heroics
Makes trade-offs explicit
Builds trust through transparency

Most importantly:

Execution becomes empirical, not performative.

A Final Thought

PI Planning is not the problem.
The problem is treating the plan as the primary execution signal.

Flow metrics—WIP, aging, and blocked time—tell us what is actually happening.

If we are serious about improving predictability at scale,
we need to manage flow during the PI, not just plan before it.