The three that survive being watched
Throughput is the count of items finished per unit of time — twelve stories a fortnight,
say. It is measured in whole completed things, which is the only unit a stakeholder cares
about, and it requires no estimate at all. That last property is what makes it durable: there
is no field a team can adjust to make throughput look better other than by finishing more
work.
Cycle time is the elapsed time from a work item starting to it being done, and the
non-negotiable point is that you report it as a distribution rather than a mean. Software work
is right-skewed, so an average sits below most of the interesting cases. Quote a median and an
85th percentile and you can make a real promise: "85% of stories of this type finish within
eleven days." Quote the mean of four days and you will be wrong in exactly the cases that hurt.
Flow efficiency is the fraction of that elapsed time in which the item was actively worked
rather than waiting in a queue. It is the metric that changes conversations, because the
result is usually startling and it points at the system rather than the people. Teams that
have never measured it typically discover most of the calendar was queueing — awaiting review,
awaiting an environment, awaiting a sign-off — and no amount of coding faster addresses that.
Underneath all three sits Little's Law, which for a stable system relates average work in
progress, average throughput and average cycle time as WIP = throughput × cycle time. Its
practical use is that it identifies the only lever you control directly. You cannot decide to
have a shorter cycle time; you can decide to start fewer things.
A worked read of one team's board
Take a team finishing 6 items a week, with 24 items in progress. Rearranging Little's Law
gives an average cycle time of 24 / 6 = 4 weeks. Now suppose the team halves its WIP limit to
12 while its capacity is unchanged, so throughput stays near 6. Cycle time becomes 12 / 6 = 2
weeks — the same output, arriving in half the elapsed time, with no one working harder. That
is the argument for WIP limits reduced to arithmetic, and it is far more persuasive to a
sceptical stakeholder than an appeal to focus.
Now add the flow-efficiency read for one representative story:
Story ACC-812 "Add IBAN validation to payee screen"
In Analysis Mon 02 -> Wed 04 2 days waiting 1.5, active 0.5
In Development Wed 04 -> Fri 06 2 days active 2
Awaiting Review Fri 06 -> Thu 12 6 days waiting 6
In Test Thu 12 -> Fri 13 1 day active 1
Awaiting Release Fri 13 -> Tue 24 11 days waiting 11 (monthly release)
Cycle time 22 calendar days
Active time 3.5 days
Flow efficiency 3.5 / 22 = 16%
Two things fall out immediately. The team's development speed is nearly irrelevant to the
delivery date, so an estimation programme or a velocity target would target the wrong 16% of
the process. And the two dominant queues — review latency and a monthly release gate — are
owned by a code-review culture and a release process respectively, one of which the team can
fix this week and one of which needs a manager. That is what a useful metric does: it names
the constraint and tells you who has to move.
Why velocity corrupts itself specifically
The general answer, that any measure used as a target loses its value as a measure, is true
and insufficient, because interviewers want the mechanism for this particular number.
Velocity is the sum of story points completed in a Sprint, and story points are a relative
unit the team defines for itself with no external anchor. It follows that the team can raise
velocity by estimating the same work higher, and this requires no dishonesty whatsoever —
merely an entirely defensible feeling, once velocity is being watched, that this work is
probably a 5 rather than a 3. Nothing about the delivered output changes. Compare throughput,
which is denominated in finished items: to raise it you must finish more items, which is the
behaviour you wanted.
There is a second, worse effect. Because points are earned on completion, a velocity target
rewards finishing many small things and punishes carrying a large valuable one across a Sprint
boundary. Teams under velocity pressure reliably slice work to make it countable rather than
to make it valuable, split stories along technical layers so each half can be closed, and
quietly relax the Definition of Done, since a story that is "done except monitoring" still
books its points. Every one of those is invisible on the dashboard.
Velocity also cannot be compared between teams, and the request to do so is the commonest
misuse. Two teams reporting 20 and 55 have told you their reference stories differ. You can
conclude nothing about either, and a candidate who tries to has failed the question.
None of which makes velocity useless. As an internal input to how much a team pulls into the
next Sprint, using its own recent range rather than a single figure, it is fine. It stops
working when it leaves the room. Worth noting too that neither velocity nor story points
appear in the Scrum Guide at all, so a team is free to drop both.
Forecasting without pretending
The reason flow metrics matter commercially is that they produce a forecast you can defend.
Take the team's weekly throughput from the last ten or twelve weeks — say the samples run
between 4 and 9 items — and simulate the remaining backlog by drawing repeatedly from those
samples. The output is a distribution of completion dates rather than a single one, so you can
say "60 items remaining, 85% likely to complete within twelve weeks, 50% within nine". That
uses only observed history and makes its uncertainty explicit, which is exactly what a plan
built from a single velocity figure conceals.
The answer to give leadership always has three parts: a range, a confidence level, and a
lever. "Twelve weeks at 85% confidence; if the date has to be week nine, here is the scope I
would drop." A single date is a promise you cannot keep, and a refusal to give a date is read,
correctly, as evasion.
What none of this measures
Be the candidate who volunteers the limits. Every metric above describes flow, and flow is
not value: a team can move worthless work through a beautifully efficient pipeline. Pair them
with something about outcome — adoption of the feature, the support-ticket volume it was meant
to reduce — or you have optimised a conveyor belt to nowhere. They also say nothing about
quality on their own, which is why change failure rate and escaped-defect counts belong
alongside, and why the DORA metrics pair delivery speed with change failure rate and recovery
time rather than reporting speed by itself. And no metric here should be attached to an
individual; the moment it is, you are measuring a person using a number generated by a system
they only partly control.
Prefer metrics denominated in units the team cannot redefine, report them as distributions,
and always publish the one that shows you where the waiting happens.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).