Flow Metrics for Accelerated Delivery

Summary

The basic measures of flow are:

• Cycle Time: The elapsed time between when an item starts and when it is done
• WIP: The number of items in progress – started but not finished
• Work Item Age: The amount of time between when work on an item started and the current time: how long an item has been in progress.
• Throughput: The number of items finished per unit of time (per day, per week, per sprint and so on).
• Flow Efficiency: How much work in progress is actually in progress vs. waiting in a queue.

Both WIP and Work Item Age are leading indicators – they provide actionable signals that enable recovery of flow stability. Cycle Time and Throughput are lagging indicators – they indicate the consequences of how well WIP and Aging are controlled.

Cycle Time

Cycle Time is the elapsed time from an item entering entering a process and departing. That is. the amount of time an item spends in the ‘In Progress’ state, or the amount of time an item spends as ‘Work In Progress’. Or, the amount of time an item spends inside a process: Between To Do and Done. The Cycle Time Histogram uses past cycle time data to forecast likely delivery times. Percentile lines show the probability of tasks being completed within certain cycle time. Higher percentile lines indicate a higher likelihood of delivering your work on time.  These charts can be used to measure cycle time, forecast team performance, and identify areas for improvement. Cycle Time can be visualized using: Cycle Time Histogram: The frequency distribution of the completion times of the tasks in your workflow. The vertical axis displays a frequency and the horizontal axis shows your cycle times. The charts shows that 75% of the work items will be completed in 5 days or less, and 95% of items will be completed in 11 days or less.

Cycle Time Scatter Plot:  horizontal axis represents a selected time frame and a vertical axis represents the cycle time in days of completed tasks during that period. Dots on the chart represent completed tasks.

Throughput

Throughput is the number of items completed by a process per unit of time. Units can be anything meaningful for your operation: per hour, per day, per week, or per sprint, and so on. On a CFD Chart throughput is the slope of the cumulative done line.

By understanding throughput we can get an idea of how much of a Product Backlog can be completed in a specific time period.   The simplest way to show throughput variability is via a simple line chart:

It shows:

• Sprint-to-sprint oscillation.
• Output instability.
• Peaks and troughs.
• Batching behavior.

Throughput ranges from:

• 5 stories (low sprint)
• To 20 stories (high sprint)

That is a 4× swing. Even if average throughput is ~12 stories, leadership experiences instability. This is what unpredictability looks like at the output level. Why This Is Not Redundant with Cycle Time: Cycle time histogram shows:

• How long items take.

Throughput chart shows:

• How smooth output is.

You can have:

• Stable cycle time, unstable throughput (batching).
• Stable throughput, unstable cycle time (tail risk).
• Both unstable (overload).
• Both stable (controlled system).

They measure different system behaviors. What High Throughput Variability Usually Means: When you see large oscillation:

• WIP fluctuates.
• Stories finish in batches.
• Testing bottlenecks exist.
• Sprint-end crunch is common.
• Utilization near congestion threshold.

It often correlates with:

• Large story size variation.
• Weak WIP enforcement.
• Context switching.

What “Good” Looks Like: A stable team shows:

• Throughput clustered tightly around mean.
• Small sprint-to-sprint swings.
• No extreme peaks or troughs.
• Gradual trend improvement.

Visually, it looks like: Small wave, not jagged spikes. Predictability requires both stable cycle time and stable throughput. If either oscillates, the system is unstable.

Work in Progress (WIP)

This is measured as the number of items that have entered a process but have not yet exited. Typically the number of backlog items that are in the ‘In Progress’ state. This is an important measure for optimizing flow, and Little’s Law clearly shows the relationship between WIP and Cycle Time or Throughput:

Cycle Time = WIP/Throughput

In simple terms, increasing the amount of WIP in a process results in an increasing Cycle Time. This can be visualized using a CFD (Cumulative Flow Diagram), where WIP is the vertical distance between the arrivals line and the departures (done) line. It can be seen that stretching the WIP line will result in a corresponding lengthening of the Cycle Time line (the horizontal distance between arrivals and departures)

Work Item Age

Work Item Age (or Age in WIP) measures how long an item has been in progress. Aging can be monitored against an “SLE” (Service Level Expectation – the forecast of how long a work item should take) to manage flow and avoid bottlenecks. Once an SLE  exists aging becomes the most informative signal in the system. When a work item exceeds its expected age, the system has left its normal operating envelope. An aging breach is a significant diagnostic.

In practice, it almost always indicates one or more of the following:

• Too much work was admitted relative to capacity. The system accepted more concurrent work than it could realistically finish.
• Capacity was displaced by unplanned or higher-priority work. Effective WIP increased without reducing existing commitments.
• An unforeseen dependency or blockage materialized. External constraints delayed progress that could not be resolved locally.
• The work item was too large or poorly shaped. Hidden scope or late discovery expanded the effective batch size.

In every case, the root cause is the same: Work was admitted under assumptions that were no longer valid. That is why aging is the correct trigger for corrective action.

A Work Item Age Chart can help focus a Daily Standup.  For example a scrum team might have an SLE that says 85% of the Sprint Backlog will be done in 8 days or less). A work Item Age ‘Heatmap’ chart is an excellent tool for visualization of Work Item Age. This refocuses the standup from a discussion about what everyone on the team is working on, to a discussion about flow. And, which items might be at risk of not getting to done, and what mitigations can be taken by the team to avoid this. An aging breach surfaces risk while corrective options still exist:

• Swarming
• De-scoping
• Re-sequencing
• Stopping work altogether

 

Late signals force explanation. Early signals enable correction.

Flow Efficiency

Measures how much time is spent working on a request compared to the total time it takes to complete it. Or, how much work in progress is actually in progress vs. waiting in a queue. This metric can be used to indicate how much room for improvement is available without changing development processes. Note, Flow Efficiency explains why Cycle Time is high. Aging and WIP tell us what to control. If we regulate WIP and enforce aging policies, Flow Efficiency improves automatically.

Applying Flow Metrics in Scrum

Work Item Aging and WIP are leading indicators and these are the measures that teams should focus on daily in order to proactively manage the flow of work. Cycle Time and Throughput are lagging indicators (the data is based on work that has already been completed). These are historical data which can be input to Monte Carlo and applied for planning and forecasting purposes. Cycle Time addresses: When will it be done, and Throughput addresses: How much can we do. In both cases, the measures are expressed as a range plus a probability. A Scrum Team may primarily use each of the flow metrics as follows:

• Sprint Planning: Throughput helps create a realistic forecast for how much work can be done in the next sprint
• Daily Scrum: Focus on WIP and Work Item Age.  Item Age points the team to those items at risk of missing their SLE. By monitoring Work Item Age, we get visibility into at-risk items and can take actions to improve flow. Accumulating WIP in any workflow state can point to a number of problems and is worthy of focus during the standup so that appropriate action can be taken.
• Sprint Review: Should include a discussion about what to do next, priorities, release forecasting. Hence the throughput metric is going to be needed to backup these conversations.
• Sprint Retrospective: Is for reviewing the teams performance (Throughput and Cycle Times), and this can be made much more effective by bringing actual data into the discussion. This data can help a team identify patterns, relationships, and opportunities for improvement. More on Sprint Retrospectives here. Tools for retrospectives here.

Specific charts for visualizing each of the flow metrics are:

• WIP: Cumulative Flow Diagram
• Cycle Time: Cycle Time Scatter Plot, Cycle Time Histogram

• Throughput: Cumulative Flow Diagram, or Flow Run Chart (e.g. Throughput per Sprint)
• Work Item Aging: Work Item Age Heatmap.

It is worth noting that the Cumulative Flow Diagram (CFD) shows 3 of the core flow metrics on a single chart: Throughput, Cycle Time and WIP. (Though this chart can be difficult to extract from Jira).

What About Velocity?

Driving Improvement with Flow Metrics

Flow Metrics provide insight into what is helping or impeding a team’s processes and workflow. Understanding the relationship between Cycle Time, Throughput and WIP enables teams to improve and stabilize their processes and workflows in a highly measurable way. Regular review of this data should be a major part of the improvement process for teams. What we have here is inconsistent flow control across teams leading to unpredictable delivery – cycle time distributions with very long tails. For example:

This histogram illustrates high variability clearly:

• A dense cluster of stories completing in ~3–6 days
• A visible long tail extending out to ~20+ days
• Sparse but impactful aging outliers

Structurally, this is what instability looks like:

• Median likely around 4–5 days
• 85th percentile much higher (probably 12–15 days)
• Long right tail driving unpredictability

This kind of distribution is typical when:

• WIP is high
• Stories are inconsistently sized
• Blockers are unresolved
• Context switching is common

Our approach will be pursued in a number of steps:

Phase 1 – Establish an Objective Baseline

Purpose:

• Create shared visibility into current system performance.

Activities:

• Capture story cycle time distribution (median, 85th percentile)
• Assess WIP levels and concurrency patterns
• Measure aging exposure
• Identify variability patterns
• Surface structural bottlenecks

Outcome:

• Fact-based understanding of delivery stability
• Clear definition of current predictability
• Agreement on improvement direction

This replaces opinion with data. Start with flow diagnostics. (Do not start with an Agile maturity assessment). If we want an objective baseline that supports a delivery flow/control-system transformation, we need three signal types:

1. Time (cycle time distribution)
2. Quantity (WIP levels)
3. (Risk) Exposure (aging of in-flight work)

Those three metrics together describe system stability.

• Current Story cycle time  – Cycle Time Histogram/Scatter Chart – 85th percentile. (Or, Feature/Epic cycle times)
• WIP levels (Simple WIP vs. Time Line Chart).
• Aging distribution – work item Age Chart
• Throughput consistency

The goal is to answer:

• Where is flow unstable?
• Where is WIP excessive?
• Where is risk exposure unbounded?

This produces an objective baseline.

Phase 2 – Stabilize

Purpose:

• Reduce variability and uncontrolled exposure.

Interventions:

• Introduce or tighten WIP limits
• Enforce “Finish Before Start” policy.
• Implement aging policies
  • Add explicit aging threshold (e.g., 6 days).
  • Split aging stories aggressively.
  • Swarm on any story exceeding threshold.
  • Tighten refinement quality (DOR)
• Improve story slicing/sizing discipline – Stories must be deliverable within 3–5 days.
• Reduce context switching and parallel initiative load
• Embed flow visibility into Sprint Reviews

Outcome:

• Reduced variability
• Improved flow stability
• Early compression of long-tail cycle times

The objective is not speed — it is stability:

1. 1. 1. • WIP consistently within limits.
         • Aging breaches rare and acted upon.
         • Cycle time variability decreasing.
         • Fewer parallel initiatives.
         • Predictable throughput.

That is flow stability. Do not change everything in the organization at once. Limit transformation WIP to 2–3 structural interventions. Once teams are individually stable:

1. 1. 1. • Introduce consistent flow metrics.
         • Align definition of done.
         • Standardize WIP transparency.
         • Stand-ups based on flow signals.
         • (Create ART-level flow review if needed).

The objective is not uniformity of rituals. It is uniformity of control signals.

Phase 3 – Set Improvement Targets

Once the system begins stabilizing:

• Define realistic percentile-based improvement goals
• Set exposure thresholds (WIP & aging)
• Align teams on predictability metrics
• Agree on sustainable operating ranges

Targets are set based on data — not aspiration.

Phase 4 – Continuously Measure, Learn and Improve

Sprint Reviews (or Inspect & Adapt checkpoints – Kanban) become structured Measure & Learn checkpoints. Each sprint:

• Inspect product value delivered
• Inspect delivery stability metrics
• Identify structural causes of variability
• Adjust WIP, slicing, or workflow policies

Improvement becomes continuous rather than episodic.

Re-define Sustainable Agile as “Stable Flow”

1. 1. 1. • WIP consistently within limits.
         • Aging breaches rare and acted upon.
         • Cycle time variability decreasing.
         • Fewer parallel initiatives.
         • Predictable throughput.
         • Faster time to customer impact.

That is flow stability.

Flow Metrics Dashboard

1. 1. 1. • 85th percentile cycle time trend
         • Story aging breaches.
         • WIP limits.
         • Delivery Predictability

An improvement program should be focused on stabilizing the delivery system and embedding a measurable feedback loop that continuously improves reliability and time-to-value.