Metrics: Velocity, Throughput, and Cycle Time
Learn why throughput and cycle time offer clearer insights than velocity, helping your Scrum team spot bottlenecks and forecast delivery with greater accuracy.
Most engineering organizations measure the wrong things because story points feel scientific. When managers look at numbers, teams start optimizing the numbers instead of shipping software. Velocity, throughput, and cycle time are the three most common metrics teams use to track work, but they measure fundamentally different things. Only two of them actually help you deliver value sooner.
The problem with velocity
Story points are relative estimates created by a single team for sprint planning. The Scrum Guide never mentions story points or velocity. It simply asks Developers to size items so they can forecast what can be done in a Sprint. When leadership treats velocity as a productivity metric, estimation inflation occurs. A team that delivered 20 points last sprint will estimate a five point story as an eight point story this sprint. Nothing moves faster, but the chart points up.
Velocity is an internal calibration tool for a single group, not an external measure of output. It cannot be compared across teams because each team invents its own scale. Worse, focusing on velocity encourages teams to take on large batches of work to maintain high numbers, which increases risk and delays feedback.
Why throughput works better
Throughput measures completed work items per unit of time, such as items finished per week or per Sprint. It does not care about story points. A bug fix counts as one, and a refactored payment module counts as one. Only items that meet the Definition of Done count.
Counting items sounds crude until you look at the math. In software, variation in item size matters far less than variation in queue length and delay. When teams break user stories down into small, coherent pieces of value, counting completed items provides forecasts that match or beat estimates based on story points. It also eliminates lengthy arguments over whether a task is three points or five points.
Cycle time reveals where work gets stuck
Cycle time tracks how long an item takes from the moment work begins until it reaches the Definition of Done. If a developer starts writing code on Monday and the feature reaches production on Thursday of the following week, the cycle time is nine working days.
Unlike velocity, cycle time points directly to friction in your delivery process. High cycle times rarely come from slow typing. They come from work waiting in queues: waiting for code review, waiting for testing, or waiting for environment deployment. If you want to finish work faster, look at your cycle time distribution instead of asking people to work harder.
Building a better measurement habit
You do not need complicated metric dashboards to understand your progress. If you want a healthy delivery process, watch three practical indicators:
- Work in progress limits to prevent bottlenecks and keep cycle times low.
- 85th percentile cycle time to provide realistic completion forecasts to stakeholders.
- Throughput per sprint to understand real capacity without point estimation games.
The Scrum Guide reminds us that the purpose of each Sprint is to produce a valuable, useful Increment that meets the Definition of Done. Velocity tells you how much work you thought you were doing. Throughput and cycle time show you what actually got done and how long it took to get there.