Most engineering teams that adopt DORA metrics eventually hit the same wall. Deployment frequency is improving. Lead time is coming down. And yet the business is still frustrated that the things they asked for six months ago haven't shipped. The features are done — so why does everything still feel slow?
The answer is usually found upstream of deployment. DORA metrics measure what happens once work enters your engineering pipeline. Flow metrics measure the entire journey from idea to customer value, including all the waiting, queuing, and context-switching that happens before a line of code is written.
What the Flow Framework measures
Flow metrics come from Mik Kersten's Flow Framework, developed from research into how value moves through software organisations. There are five core metrics:
- Flow velocity — the number of flow items completed per unit of time. Think of it as your throughput: how much business value is actually shipping.
- Flow time — the elapsed time from when a flow item is created to when it is delivered. This is the end-to-end measure that business stakeholders actually care about. A feature that takes three weeks to build but sat in a backlog for four months has a five-month flow time.
- Flow efficiency — the ratio of active time to total flow time. If a feature spends 10% of its life being actively worked on and 90% waiting, your flow efficiency is 10%. For most organisations, this number is shockingly low — often between 5% and 20%.
- Flow load — the number of flow items currently in progress across your system. High flow load is a leading indicator of declining velocity and increasing flow time, because context-switching and coordination overhead increase as WIP rises.
- Flow distribution — the breakdown of work by type: features, defects, risk (security, compliance, technical debt), and debt. This tells you whether your investment mix matches your strategic priorities.
Flow time versus lead time: why the difference matters
DORA's lead time for changes measures from commit to production — typically hours or days for a well-functioning team. Flow time measures from request to delivery — typically weeks or months for almost any organisation. Both numbers are real and both matter, but they answer different questions.
Lead time tells you about your deployment pipeline. Flow time tells you about your entire product delivery system, including discovery, prioritisation, design, and the queues between each stage. A team can have excellent lead time and terrible flow time simultaneously — fast at deploying once work is picked up, slow at actually getting work to the point where it's picked up.
If you only measure lead time, you'll optimise the last 10% of the delivery process and wonder why it doesn't feel like much has changed.
Flow efficiency: the number that humbles everyone
Of all the flow metrics, flow efficiency is usually the most confronting. When I baseline this with teams, the typical finding is that work is actively being progressed for somewhere between 5% and 25% of its total journey through the system. The rest of the time it is waiting — in a backlog, in a review queue, blocked on a dependency, sitting in a test environment queue, awaiting sign-off.
The implications are significant. If your flow efficiency is 15%, the theoretical maximum improvement from making your engineers work faster is small — you can only speed up the 15%. The remaining 85% is waiting time, and making people work faster doesn't reduce waiting. What reduces waiting is reducing WIP, removing handoffs, and eliminating the approval and queuing steps that accumulate in mature organisations.
This is why Flow and Lean thinking are so closely related. The original insight from Toyota Production System — that waste in a process is overwhelmingly waiting rather than activity — translates directly to software delivery.
Flow load and the WIP problem
Flow load is a leading indicator: it predicts future performance rather than reporting past performance. When flow load rises, flow time rises shortly afterwards. This makes intuitive sense — the more things are in progress simultaneously, the more time each individual thing spends waiting for attention.
Most engineering organisations have too much in flight. Product teams feel pressure to start new things before old things are finished. Engineers get pulled across multiple streams. Programme managers interpret idle capacity as waste and fill it with new initiates. The result is a system where nothing moves quickly because everything is competing for the same attention.
Limiting WIP is one of the highest-leverage interventions available in a slow-moving delivery organisation, and it's also one of the most politically difficult. Telling a stakeholder that their project will be started later so that the things already started can actually finish requires confidence in the data.
Using Flow and DORA together
DORA and Flow metrics are complementary, not competing. I use them together as two layers of the same diagnostic:
Start with Flow metrics to understand where time is being lost across the whole delivery system. Flow time and flow efficiency will point you to the stages where work accumulates. Flow load will tell you whether WIP is the root cause. Flow distribution will tell you whether technical debt or defects are consuming capacity that should be going to features.
Then use DORA metrics to diagnose the engineering pipeline specifically. Once Flow analysis has told you that the deployment and release phase is a bottleneck, DORA metrics give you the detail you need to understand what's happening inside it.
Together they let you have precise conversations with both business and engineering stakeholders — using the language each group finds meaningful — about the same underlying delivery system.
Getting started
You don't need sophisticated tooling to begin. Most teams can bootstrap a Flow analysis using their existing issue tracker — Jira, Linear, GitHub Issues — by extracting creation dates and completion dates for work items over the last three to six months. Flow time and a rough approximation of flow efficiency can be calculated from that data alone.
The value is in the pattern, not the precision. When you plot flow time over a period and see it trending upward, or calculate flow efficiency and find it's 8%, the direction of improvement is clear even if the exact numbers have measurement error. Start with the data you have, then invest in better instrumentation once you know what you're trying to measure.
Back to Insights