Flow Efficiency

---

The Definition

Flow efficiency = (active work time / total elapsed time) × 100%.¹

For a story that takes 14 elapsed days, of which the team actively worked on it for 3 days (the rest being waiting in queues, blocked on dependencies, or in review limbo), flow efficiency = 3/14 = 21%.

The metric reveals what aggregate cycle time hides: most of the time most work spends in the system, no one is actively working on it.

The Typical Numbers

Empirical studies and industry surveys consistently find flow efficiency in software work between 5% and 30%, with most teams clustered between 10% and 20%.² A team that has never measured before usually discovers a number lower than they expected.

For comparison: lean manufacturing aspires to flow efficiencies of 70%+. Software work has fundamentally different dynamics — research, review, integration — that make pure manufacturing comparisons unfair. But the order-of-magnitude gap between software's 15% and manufacturing's 70% is still revealing.

Why The Number Is So Low

Software work spends most of its elapsed time in queues:

• Backlog wait — the request sat in the backlog before being prioritized.
• Pre-refinement wait — waiting for the team to refine before pulling.
• Pre-development wait — sitting in Ready while other items are in progress.
• Review wait — PR submitted, waiting for reviewer.
• Test wait — built but waiting for QA bandwidth.
• Deploy wait — tested but waiting for release.
• Blocked time — waiting on dependencies, decisions, or other teams.

Each wait is small individually. Together they routinely consume 80–95% of an item's calendar life.

Why Measuring It Matters

Most teams optimize the wrong thing. They try to make the active work faster — more skilled developers, better tooling, more pairing. These investments often improve flow efficiency by 1–2 percentage points and feel like enormous effort.

Meanwhile, the wait times that consume 80% of calendar life remain unaddressed. Removing one significant wait (e.g., reducing average review wait from 2 days to half a day) typically improves flow efficiency by 5–10 percentage points for trivial cost.

Measuring flow efficiency redirects the team's attention from active-time optimization (low leverage) to wait-time elimination (high leverage).

How to Measure

The most reliable approach:

• Pick a sample of recently completed items (10–30).
• For each, measure total elapsed time (start to done).
• For each, estimate active work time (the cumulative time someone was actually working on it).
• Calculate efficiency for each, then aggregate.

The "active work time" estimate is the hardest part. Some teams use Pomodoro-style logging; some sample by interviewing the assignee for each item; some use rough estimates from time-tracking tools. The number doesn't need to be exact — it needs to be in the right ballpark to be useful.

What to Do With The Result

The metric is most useful as a diagnostic prompt. A low number (15%) prompts:

• Where are the biggest waits? Map them.
• Which waits could be eliminated entirely? (e.g., self-merge for trivial PRs.)
• Which waits could be reduced? (e.g., faster review SLA.)
• Which waits are external? (e.g., waiting on another team — addressable through better service boundaries.)

The goal isn't to maximize flow efficiency. The goal is to understand which waits are accidental and which are essential, and to eliminate the accidental ones.

Common Failure Modes

• Treating flow efficiency as a target. Aiming for 80% in software produces gaming. The metric reveals patterns; targeting it kills the signal.
• Measuring without acting. The metric on its own is just discomfort. The value is in the wait-time elimination.
• Over-precise measurement. Spending two weeks calculating exact flow efficiency to two decimal places. The order of magnitude is what matters.
• Comparing across teams. Different work has different essential waits. Cross-team comparisons distort.

Coaching Tips

Measure once and act.

A single accurate measurement is better than continuous noisy measurement. Measure, identify the biggest waits, address them.

Map the waits explicitly.

List every wait in the typical item's journey. Sort by total time. Address the longest first.

Don't target the number.

"Improve flow efficiency to 40%" produces gaming. "Reduce review wait from 2 days to half a day" produces results.

Distinguish essential from accidental waits.

Some waits are necessary (security review of high-risk code); some are accidental (review wait because no one's checking). The accidental ones are the leverage.

Use the discomfort productively.

The first measurement is uncomfortable. That discomfort is the energy that drives improvement — channel it.

Re-measure after improvements.

Six months later, measure again. The trend matters more than absolute numbers.

Summary

Flow efficiency is one of the most uncomfortable and useful metrics in flow practice. By revealing that 80–95% of an item's calendar life is spent waiting, it redirects improvement effort from active-work optimization to wait-elimination. The numbers are typically low; the leverage on improvements is high. The discipline is to measure honestly, act on the patterns the measurement reveals, and resist the temptation to turn the metric into a target. Teams that engage with flow efficiency seriously usually find improvements that pure cycle-time analysis would never have surfaced.

Back to Flow & Forecasting