Delivery metrics: definitions and limits

Every metric here is a signal about a system, not a grade for a person. That is not a disclaimer, it is a design constraint — and it is why the set is short and why none of it is per-individual.

The mechanism it protects against is simple and entirely predictable. If a forecasting number becomes a performance number, people inflate estimates. Not through dishonesty — through reasonable self-protection. And then you have destroyed the only forecasting instrument you had, permanently, because you cannot un-teach that lesson.

Commitment accuracy

Measures: how closely the team delivers what it committed to at planning.

Calculation: completed / committed, per iteration, as a percentage.

Does not measure: productivity, effort, or whether the amount committed was ambitious. A team at 100% may be under-committing comfortably.

How to read it: the useful signal is the pattern, not the number. Consistently low suggests planning is absorbing work it should not, or that estimates are optimistic. Consistently at exactly 100% suggests the commitment is being set after the fact. Volatile suggests interruption.

Delivery rate stability

Measures: the consistency of throughput across iterations.

Calculation: the trend of completed units per iteration. A reasonable target is variation within roughly ±15% over several iterations.

Does not measure: speed. A stable slow team is more valuable to a business than an erratic fast one, because you can plan around it.

How to read it: treat a drop as a question about the system — unclear scope, context switching, growing test debt, someone absent — not as a question about the people. Never compare the number between teams; the units are not commensurable and everyone knows it, which is why comparison mostly produces inflation.

Defect escape rate

Measures: how many defects reach production relative to all defects found.

Calculation: defects found in production / total defects found, over a period.

Does not measure: code quality in the abstract, and it is not a count of bugs. A team that finds a lot of defects early looks worse on the raw count and better on this ratio, which is the correct incentive.

How to read it: a reasonable target is below 10–15%. Rising means testing is happening too late or the definition of done is incomplete. Very low with few defects found at all usually means defects are not being recorded, not that they do not exist.

Planned versus unplanned work

Measures: how much of an iteration was consumed by work that was not planned into it.

Calculation: unplanned units completed / total units completed.

Does not measure: whether the unplanned work was worth doing. Some of it always is.

How to read it: above roughly 20% and the team cannot commit to anything meaningfully — and that is a conversation about stakeholder expectations, not about the team. This is the single most useful metric for defending an iteration boundary, because it turns “we keep getting interrupted” into a number.

One implementation note: label the work as unplanned at the moment it enters, as part of accepting it. Reconstructing it at the end of the iteration does not work; nobody remembers accurately.

Team health

Measures: how the team is actually doing.

Method: an anonymous three-question check every four to six weeks. Workload sustainability, whether ways of working are improving, whether people have what they need.

Does not measure: individual satisfaction — the sample is deliberately too small to attribute, and it must stay that way or the answers stop being honest.

How to read it: only the trend. A single round is noise. And it must feed a retrospective, because a survey that produces no visible change teaches people that answering is pointless — which is worse than never asking.

Choosing your own set

Three rules that keep a metric set from decaying into a dashboard nobody reads.

Write what each metric does not measure, next to it. This is the strongest filter for whether a metric deserves to exist. An indicator you cannot describe the limits of will be misused eventually — not maliciously, just by someone reading it without context in a quarterly review.

Prefer aggregate over individual, always. Anything that measures a person gets used to evaluate them eventually, whatever the original intention. If a specific person is struggling, that is a conversation, not a chart.

Store snapshots rather than only showing current state. A metric that cannot answer “was this better last quarter” cannot support a decision. It also means the number someone saw last week still exists, unchanged, when they ask about it this week.