Which delivery flow metrics reveal where the constraint actually is, and what do they typically show?
Show the full answer Hide the answer
The metrics
1. Lead time from commitment to production, decomposed by stage — waiting for prioritisation, in development, in review, in test, waiting for release, deployed but not enabled.
2. Flow efficiency: active work time divided by total elapsed lead time. This is the most diagnostic single number and it is almost always far lower than teams expect.
3. Work in progress, since queue length drives wait time and reducing concurrent work counter-intuitively increases throughput.
4. Queue time at each handoff, which is a function of the receiving team's utilisation.
5. Batch size — change size and release size — which is both a cause and a symptom.
6. Deployment frequency and change failure rate together, since either alone is gameable and they are in tension.
What they typically show
That engineering is not the constraint. Work time is usually a small fraction of lead time, so doubling engineering productivity improves delivery by a small amount — which is why teams that get measurably faster still deliver at the same pace and nobody can explain it.
The wait is typically before work starts (backlog, unowned decisions — the largest block, and invisible because the clock has not started), at handoffs to fully-utilised specialist teams, in batching for a release train, in approvals, and after release in the gap between deployed and enabled.
The counter-intuitive finding
The process is optimised for utilisation rather than for flow. A team kept fully busy maximises its own efficiency and maximises the queue in front of it. Deliberate slack in the constrained step reduces total lead time even though it lowers that team's utilisation — which is rarely done without the measurement to justify it.
The caution
These metrics are a health check, not a performance evaluation. Used for comparison between teams or attached to consequences, they become the thing optimised and stop describing the system — deployment frequency rises by splitting trivial changes, lead time falls by decomposing for the metric.