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

Author: Marin Niehues, Niehues Consulting · Published: 2024-07-25 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/agile-team-metrics/

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.

**A metric serves leadership when it derives from work that has actually been completed, can be compared across teams and triggers a decision. Velocity does derive from completed work, but it fails the second condition and meets the third only within the team.**

## 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](/en/blog/flow-metrics-throughput-wip-wait-time/), and the limiting of parallel work in the article on [limiting work in progress](/en/blog/limit-work-in-progress-deliver-faster/).

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.

**Two levels, two audiences**
- For the team: velocity or number of completed items, Sprint Goal attainment, age of work on the board. These numbers steer daily work and are discussed within the team.
- For management: cycle time, throughput, stability of delivery and an outcome measure owned by the business unit. These numbers guide priorities and investment.

## 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](/en/blog/cost-of-delay/) develops.

**Metrics compared**
Metric | What it shows | Suitable for management | Main risk
Velocity | Story points per sprint, a team-internal estimate | No, only as a planning aid within the team | Inflated estimates under target pressure
Cycle time | Time from start to completion | Yes, comparable across teams | The average hides the spread
Throughput | Finished items per period | Yes, with an eye on item size | Raised by splitting work into tiny tasks
Work item age | Age of started work | Yes, as an early warning of delay | Only useful with an honestly maintained board
Deployment frequency and stability | Speed and quality of delivery | Yes, the core of the report for software | Requires automated measurement
Outcome measure of the business unit | Effect for the customer or in the process | Yes, the most important number | Needs a named owner

## 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](/en/blog/delivery-forecasting-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](/en/) 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](/en/#kontakt). Scope and terms of an engagement are discussed there.

**Conclusion**
Management needs a few numbers that derive from completed work and compare across teams: cycle time, throughput, age of work and an outcome measure with an owner. Velocity stays with the team, where it supports planning. A report built on these numbers replaces the question of utilisation with the question of flow and triggers decisions that previously disappeared inside the report.

**Sources**
- Schwaber, Sutherland: The Scrum Guide, 2020
- Scrum.org, Vacanti, Yeret: Kanban Guide for Scrum Teams, 2021
- Little, John D. C.: A Proof for the Queuing Formula L = λW, Operations Research, 1961
- Forsgren, Humble, Kim: Accelerate, book based on multi-year studies, 2018
- Strathern, Marilyn: Improving Ratings, Audit in the British University System, European Review, 1997
- Scrum.org: Evidence-Based Management Guide, 2020

## Frequently asked questions

### What is a good velocity for a Scrum team?

There is no good velocity in absolute terms, because its size follows the estimation scale of the individual team. Only its trend within the same team carries meaning. A stable velocity over several sprints shows that planning matches capacity.

### Can you compare velocity between teams?

No, comparing velocity between teams leads to wrong conclusions, because each team scales its story points differently. Cycle time and throughput are comparable, since they are measured in days and items.

### Which metrics does a Kanban team need?

A Kanban team needs cycle time, throughput, work in progress and work item age. The Kanban Guide for Scrum Teams describes these four measures, and they can be calculated from board timestamps without anyone having to estimate.

### What are DORA metrics?

DORA metrics are four measures of software delivery: deployment frequency, lead time for changes, change failure rate and time to restore service. They come from the research of the DevOps Research and Assessment team, evaluated in the book "Accelerate".

### How do you measure the success of an agile team?

The success of an agile team is measured by the effect of its delivery, that is, an outcome measure of the business unit such as customer satisfaction, process time or revenue contribution, supplemented by cycle time and stability. Activity counts such as the number of closed tickets describe the utilisation of the team.

### Which agile metrics should executives see?

Executives should see four values per team over a twelve-week trend: cycle time, throughput, the oldest item in progress and an outcome measure. These four fit on one page and show where decisions are due.

### What is Goodhart's law?

Goodhart's law states that a measure loses its meaning once it is made a target. The widely used wording comes from Marilyn Strathern in 1997. For teams it follows that metrics steer the work and stay out of bonuses and appraisals of individuals.

### How often should management review team metrics?

As a guideline of this article, a rhythm of two to four weeks suits leadership, because trends only gain meaning over several weeks. The teams themselves review their numbers in the sprint rhythm or weekly.