Agile Team Metrics: Velocity, Throughput and What Management Should See

Management should see four metrics from agile teams: cycle time, throughput, the age of work in progress and an outcome measure owned by the business unit. Velocity belongs to the team as a planning aid. It is a poor steering measure for leadership, because it cannot be compared across teams and loses its meaning once targets attach to it. Organisations that draw this line get numbers on which commitments to customers and the executive board can rest.

This article sorts the common metrics of agile teams by purpose, shows which serve leadership and provides a checklist for reporting. It is written for managing directors, heads of department and programme leads who receive weekly reports from teams and want to know which number allows a decision.

What is velocity, and why does it not work for management?

Velocity is the sum of the story points a team completes in a sprint, and it does not work for management because story points are an estimation unit internal to the team. One team that rates a task at five points and another that rates the same task at thirteen can be equally fast, because each team sets its scale by its own yardstick. The Scrum Guide of 2020 knows neither story points nor velocity. It asks for a Sprint Backlog, a Sprint Goal and an Increment that meets the Definition of Done. Velocity is a practice that grew up around Scrum.

Within a team it still does useful work. Anyone who observes over several sprints how many points a team completes can size the next sprint planning realistically. Once the number appears in a report to the executive board and is attached to a target, however, its behaviour changes. The British anthropologist Marilyn Strathern gave the widely used wording of Goodhart's law in 1997: when a measure becomes a target, it ceases to be a good measure. Teams then inflate their estimates, cut tasks smaller or close work that meets the Definition of Done in name only. Velocity rises while customer benefit stays where it was.

Which metrics show how well a team delivers?

The flow metrics from Kanban practice, described in the Kanban Guide for Scrum Teams of 2021, give the most reliable picture. They are four measures that can be calculated from the timestamps on a board without any additional estimating.

Cycle time measures the span between starting work on an item and finishing it. Throughput counts how many items are finished in a period, for example per week. Work in progress counts how many items have been started and not yet completed. Work item age states how long a started item has already been in the process. The first three measures are linked by a mathematical relationship that John Little proved in 1961: average cycle time equals average work in progress divided by average throughput. Anyone who wants to shorten cycle time has two levers, less work started at the same time or more throughput. The first lever is almost always cheaper. How to extract and read the values from a board is covered in the article on flow metrics, and the limiting of parallel work in the article on limiting work in progress.

Flow metrics are comparable across teams because they are measured in days and items. For items of a similar kind, a team with a cycle time of six days delivers faster than one with twelve, however it estimates. These figures can be influenced too: anyone who cuts items artificially small improves throughput and cycle time per item at the same time, without any more reaching the customer. An outcome measure that shows the benefit of the delivered items therefore always belongs next to the flow figures.

Which software delivery metrics are evidenced?

Four measures are evidenced by the research team around Nicole Forsgren, Jez Humble and Gene Kim in the study series behind the book “Accelerate” (2018): deployment frequency, lead time from change to production, change failure rate and time to restore service after an incident. The studies show that organisations that score well on these measures also do better on business outcomes. Two of the measures describe speed and two describe stability, and exactly this pairing prevents speed from being bought at the expense of quality.

For teams that ship software, these four measures make a sound core for the report. For teams outside software development, such as marketing, procurement or product planning, the same logic applies in translated form: how often something reaches the customer, how long it takes from idea to that point, how often rework is needed and how quickly an error is corrected.

How do you bring outcomes into the metrics?

Flow metrics measure speed, and speed in the wrong direction is worth nothing. Every report therefore needs at least one measure that shows whether the delivered work changes something for the customer or the business unit. The Evidence-Based Management guide from Scrum.org groups such measures into four key value areas: current value for customers, unrealised value, ability to innovate and time to market. One measure from each area is enough at the start, for example customer satisfaction after a delivery, the share of time a team spends on new features rather than on fixing faults, or the time from idea to first use.

The business unit names this outcome measure before an initiative starts and owns it. If a team delivers a great deal and the measure does not move, that is worth a decision: the initiative is adjusted or ended. Here the topic touches prioritisation by impact, which the article on the cost of delay develops.

What does reporting look like when it allows decisions?

A management report for agile teams fits on one page and shows, for each team, four values with their trend over twelve weeks (a guideline of this article, about one quarter): cycle time, throughput, the oldest item in progress and the outcome measure. The trend matters more than the single value, because it shows patterns that a reporting date conceals. A cycle time that has risen for weeks while throughput stays constant points to too much work started at once. Throughput that falls while the oldest item grows older points to a blockage that nobody has escalated.

For committing to dates, the distribution of cycle times serves better than the average. It shows the time within which 85 out of 100 items were finished, and that figure can be given to customers and the executive board as a commitment with a known level of confidence. The method behind it, simulating many possible courses from the team's own data, is covered in the article on delivery forecasts with Monte Carlo simulation.

Checklist for reporting

The following questions show whether an existing report allows decisions. Each can be answered with yes or no, and each no names a gap.

1. Do all numbers come from completed work and board timestamps rather than from estimates?
2. Are the numbers comparable across teams because they are measured in days and items?
3. Does each team have at least one outcome measure with a named owner in the business unit?
4. Does the report show trends over at least twelve weeks and not only the latest reporting date?
5. Is every number linked to a decision it triggers, such as additional capacity, an escalation or a stop?
6. Is it settled that no team is assessed or paid on the level of a metric?

The scoring is a rule of thumb of this article: with five or six yes answers, the report delivers dependable steering information. With four, a gap remains that can be closed by the next planning round. With three or fewer, it mostly measures activity, and a rework before the next planning round is worthwhile.

Metrics with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver and works as delivery manager, project manager and product owner on projects ranging from VC-funded scale-ups to DAX 40 groups. In the service area of delivery management and organisational design, this includes bringing teams and leadership to a shared view of delivery.

The approach follows the Niehues Delivery Model. Two of its test questions matter most for metrics: What is the baseline, and how do we measure success? Which metric shows after 90 days that the solution has landed? Both questions require the baseline to be recorded before the start, so that a change can be evidenced later. The entry point is a free initial consultation of 30 minutes, which you can arrange via contact. Scope and terms of an engagement are discussed there.