Flow metrics: the four numbers that predict delivery

Velocity answers 'how busy was the team,' which feels like a delivery metric and isn't one. The questions stakeholders actually ask are 'when will it ship' and 'are we on track,' and velocity can't answer either honestly — it's an effort proxy, and it's gameable. Flow metrics answer the delivery question directly, and there are only four you need. They're computed from data the work already carries, which is why they don't rot the way an estimate does.

Why velocity misleads

Velocity is story points completed per sprint, and it has three quiet problems. It measures effort, not outcomes, so a busy sprint that shipped nothing scores well. It's gameable, because points are negotiated and inflate over time. And it doesn't forecast — knowing a team did 40 points last sprint tells you almost nothing about when a specific chunk of scope will be done. It's a comforting number that answers the wrong question, which is worse than no number at all. The honest alternative is to measure cycle time, not activity.

The four numbers

Flow has four metrics, each answering a distinct question. Work-in-progress — how much is started but not finished — answers 'are we overloaded.' Cycle time — how long an item takes from start to done — answers 'how fast does work move.' Throughput — items finished per period — answers 'how much do we actually complete.' And work-item age — how long an in-progress item has been open — answers 'is anything stuck right now.' Together they describe the whole system, not just its output.

Little's Law ties them together

These four aren't independent; they're bound by Little's Law, which relates work-in-progress, throughput, and cycle time. The practical consequence is blunt: raise WIP without raising throughput and cycle time stretches proportionally. That's why limiting work-in-progress is the cheapest lever in software delivery — it lowers cycle time without hiring anyone or working longer, purely by not starting more than the system can flow. It's the mechanism behind why teams that keep work in flow ship faster than teams that start everything at once.

Throughput powers the forecast

To forecast delivery, you don't need estimates — you need throughput. Count how many items the team completes per period, and you can simulate forward probabilistically: given this recent throughput and this much remaining scope, here's the range of likely finish dates and the confidence for each. That's a real forecast, and it's estimate-free, which is the entire argument of forecasting delivery without estimating. A range with a confidence level is more honest than a single committed date, and it's built from measurement instead of negotiation.

Age is the early warning

Work-item age is the metric that catches slips while you can still do something about them. Velocity only tells you about a miss after the sprint ends; age tells you today that an item has been open longer than the team's usual cycle time, which is a slip in progress. Watching the aging items — and asking what's blocking each one — is how you intervene early instead of explaining late. It's also a direct read on flow efficiency: an old item is usually one that's spent most of its life waiting, not being worked.

Why flow metrics don't rot

The reason flow metrics stay honest is structural. They're computed from the timestamps work already has — when an item started, when it finished — not from an estimation ceremony someone has to keep performing. Nobody has to remember to update a point value or refresh a burndown; the numbers fall out of the work moving through the system. That's the same reason DORA-style measures stay trustworthy when they're read from the pipeline rather than curated for a slide, a point made in DORA metrics without the theater. Start from the performance pillar.