Which delivery metrics would you actually track for a team, and why does velocity stop working the moment you set a target for it?

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.