Understanding Metrics: Velocity, Throughput, and Cycle Time
Learn about key Scrum metrics: velocity, throughput, and cycle time. Understand their purpose and how to use them to improve your team's process.
Scrum teams often look for ways to understand their progress and improve. Metrics can help with this. Three common metrics you hear about are velocity, throughput, and cycle time. While the Scrum Guide does not prescribe specific metrics, these can be useful tools for transparency and inspection. Used correctly, they provide data for adaptation. Used poorly, they become targets that distort behavior. Let us look at what each means and how to use them effectively.
Velocity: A Planning Tool, Not a Performance Measure
Velocity measures the amount of work a Scrum team completes in a Sprint. It is typically expressed in story points or ideal days. For example, if a team finishes items totaling 30 story points in one Sprint, their velocity is 30. Its primary use is for forecasting. Over several Sprints, a team's velocity tends to stabilize. This allows the team to estimate how much work they can realistically pull into future Sprints. The Product Owner can use this information to project when a certain amount of functionality might be ready. Velocity is for the team's internal use and should not be compared between teams. Different teams have different definitions of a story point, making cross-team comparisons meaningless and harmful.
Throughput: Counting Completed Items
Throughput is simpler than velocity. It is the number of items completed in a given time period. Instead of summing story points, you count the number of Product Backlog items moved to 'Done' in a Sprint or over several Sprints. For instance, if a team completes 7 Product Backlog items in one Sprint, their throughput for that Sprint is 7. Throughput is useful for understanding the flow of work. It can highlight if a team is consistently breaking down work into similar sized items. If item sizes vary wildly, throughput might fluctuate, but it still provides insight into the rate of delivery. Like velocity, throughput helps with forecasting, especially when work items are roughly the same size.
Cycle Time: How Fast Work Flows
Cycle time measures the time it takes for a single item to go from 'in progress' to 'Done'. It is usually measured in hours or days. A shorter cycle time means work is flowing faster through the system. For example, if a team starts work on an item on Monday and finishes it on Wednesday, its cycle time is 3 days. This metric is a strong indicator of efficiency and responsiveness. Long cycle times often point to bottlenecks, handoffs, or excessive work in progress (WIP). Reducing cycle time means customers get value sooner.
Why These Metrics Matter for Inspection and Adaptation
These metrics are not about judging performance. They are data points for the Scrum Team to use during Sprint Reviews and Retrospectives. They help the team understand their process and identify areas for improvement. For instance:
- If velocity is highly erratic, the team might need to improve their estimation techniques or better define 'Done'.
- If throughput is low, the team might be taking on too many large items or struggling with dependencies.
- If cycle time is consistently high, the team might have too much Work in Progress, leading to context switching and delays.
Focus on Trends, Not Single Points
Do not fixate on a single Sprint's numbers. Look at trends over several Sprints. A single low velocity Sprint might be an anomaly due to unforeseen impediments. A consistent downward trend, however, signals a systemic issue that needs addressing. The goal is continuous improvement, not hitting an arbitrary number. The Scrum Team owns these metrics and uses them to make informed decisions about how they work.
Context is Key
Metrics without context are misleading. Always understand what factors might influence the numbers. A team learning a new technology might see a temporary dip in velocity. A team focusing on reducing technical debt might have lower throughput but deliver higher quality. The Scrum Team decides which metrics are most useful for their current situation and goals. These metrics are tools to help the team become more effective, transparent, and predictable, in line with Scrum's empirical pillars.