Understanding Scrum Metrics: Velocity, Throughput, and Cycle Time
Explore essential Scrum metrics like velocity, throughput, and cycle time. Learn what they measure, how to use them effectively, and common pitfalls to avoid for improved team performance and forecasting.
Many teams measure things. This is good. Measurement helps you understand what is happening and predict what might happen next. But not all metrics are equal, and some are often misused. For Scrum Teams, understanding velocity, throughput, and cycle time is key to improving how they deliver value. These metrics are tools. Use them to inspect and adapt, not to judge or compare.
Velocity: What it is and is not
Velocity measures the amount of Product Backlog Items a Scrum Team completed in a Sprint. It is usually expressed in story points or item count. For example, a team might complete 30 story points in one Sprint, then 35 in the next. This gives the team a historical average of work completed per Sprint. It is a useful input for the Developers when planning future Sprints, helping them forecast how much work they can realistically pull into a Sprint. It is also an input for the Product Owner for long term forecasting.
However, velocity is an internal team metric. It is specific to one team, its definition of done, and its sizing practices. You cannot compare velocities between different teams. Doing so is like comparing apples to oranges. It tells you nothing useful and often leads to bad incentives. Velocity should also not be used as a performance target. If you tell a team to increase its velocity, they will likely inflate story point estimates without delivering more actual value.
Throughput: A simpler measure
Throughput is simpler than velocity. It is the number of Product Backlog Items completed over a period. For example, a team might complete 7 items in one Sprint, 8 in another, and 6 in a third. This metric is less abstract than velocity because it does not rely on subjective estimation units like story points. It simply counts completed items.
Throughput can be especially useful for teams that have consistent item sizes or have broken down their work into very small, similar-sized pieces. It offers a direct count of delivered work, making it easy to understand and track over time. Like velocity, throughput helps with forecasting and understanding a team's capacity. It is still an internal team metric, not for comparison.
Cycle Time: Focus on Flow
Cycle time measures the total time it takes for a Product Backlog Item to go from when work starts on it to when it is done. It is the duration from the moment a Developer pulls an item into 'in progress' until it meets the Definition of Done. For example, if an item is started on Monday and finished on Friday, its cycle time is five days.
Lower cycle times mean faster delivery. This metric is excellent for identifying bottlenecks and improving the flow of work. If cycle times are high, it often points to delays in review, testing, or handoffs. Reducing cycle time means value gets to users faster, and feedback loops shorten. This is a powerful metric for continuous improvement.
When to use which metric
The choice of metric depends on what you want to understand and improve:
- Use Velocity or Throughput for Sprint Planning and Release Forecasting: To help Developers understand how much work they can commit to in a Sprint and for the Product Owner to forecast when a larger set of features might be ready.
- Use Cycle Time to Identify Bottlenecks and Improve Flow: To understand how long it takes to deliver individual items and pinpoint areas where work gets stuck or delayed.
- Use all of them for Transparency and Inspection: To provide data points for the Scrum Team to discuss during the Sprint Retrospective, identify trends, and formulate experiments for improvement.
Common Pitfalls to Avoid
Treating these metrics as performance indicators for individuals or for comparing teams is a mistake. This leads to gaming the system, not actual improvement. Focus on the trend over time, not individual data points. A stable velocity or throughput allows for more reliable forecasting. A decreasing cycle time indicates improved efficiency and flow. Use these metrics to foster transparency and support the Scrum Team's self management and continuous improvement efforts, not to control them.