Velocity vs Throughput – What’s the difference?

In the context of software delivery, velocity and throughput are two performance metrics used to measure the effectiveness and efficiency of a development team. They help stakeholders and teams understand the progress and productivity of software development processes. While both metrics provide valuable insights, they have different focuses and should be used for different purposes.

In order to understand velocity, you need to understand story points as well.

Story Points:

1. Story points are a relative estimation technique that is used to measure the size, complexity, and effort required to complete a user story or task.
2. They are typically expressed as numbers, often using a Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.)
3. Story points provide a way for teams to estimate how much work they can complete in a sprint, allowing them to prioritize tasks and manage their workload effectively.

Velocity:

1. Velocity is a relative measure: It is essential to note that velocity is a team-specific metric and can vary from one team to another. Comparing velocities between different teams might not provide meaningful insights.
2. Historical data: Velocity is calculated based on historical data, typically from the past few sprints or iterations. This information helps teams estimate their future performance and adjust their workload accordingly.
3. Aids in planning: By knowing their velocity, teams can better predict how much work they can complete in future sprints, helping them set achievable goals and manage stakeholder expectations.
4. Continuous improvement: Teams can use velocity to identify areas for improvement in their processes and workflows. By analyzing variations in velocity, teams can detect bottlenecks or inefficiencies and take corrective actions.
5. Not the only metric: Although velocity is a helpful measure, it should not be the only metric used to assess a team’s performance. Other factors, such as code quality, customer satisfaction, and technical debt, should also be considered to gain a comprehensive understanding of a team’s effectiveness.
6. Avoid misuse: Velocity should not be used as a tool for pressuring teams to increase their productivity. Instead, it should be employed as a means for the team to self-reflect, adapt, and improve their processes, keeping in mind the primary goal of delivering high-quality software.

Throughput:

1. Throughput is a metric that measures the number of user stories or tasks a team completes over a specified period, usually weekly, bi-weekly or an iteration. They can be any type of mix, Ie stories, bugs etc. For example, if I had 10 tickets done per week over 3 weeks. My throughput per week would be 10. If I had 10 tickets, 5 tickets and 15 tickets over the 3 week period, it would be 10 as well.
2. Throughput helps teams monitor their productivity, track progress, and identify bottlenecks or areas of improvement. A true test of productivity is dora metrics. You can apply these to the team or organization level.
3. By analyzing throughput, teams can predict their future performance and adjust their work processes to optimize efficiency. You could use probabilistic forecasting to determine a forecasted date but more on that another time.

When to use Velocity vs Throughput over the other:

• If you are using Scrum, you will more than likely use Story points and Velocity
  • Use story points when you need to estimate the effort required to complete tasks and plan sprints. They are helpful in facilitating team discussions, aligning expectations, and prioritizing work.
• If you are using Kanban / Lean you will more than likely use throughput, cycle time and lead time
  • Use throughput when you want to measure the actual performance of a team and analyze historical data to predict future outcomes or identify areas for improvement.
• If you are using scrumban (a combo of both) you could use some sort of hybrid metrics approach where you have story point estimates and throughput. This will depend on the team + comfort of the product owner / flow master / sm.

Downsides to velocity/story points in software delivery:

1. Subjectivity: Estimations can vary greatly between team members, leading to inaccurate predictions and potentially causing scope creep or deadline issues.
2. Inconsistency: Different teams may use different scales or methods for assigning story points, making it difficult to compare performance across teams or projects.
3. Learning curve: It takes time for team members to become proficient at estimating story points accurately, which can lead to initial discrepancies.
4. Overemphasis on estimation: Teams might focus too much on the accuracy of story point estimation instead of delivering value and improving their processes.
5. Resistance to change: Some team members may resist using story points, as they might perceive it as an additional layer of bureaucracy or as a way to micromanage their work.
6. Beware of velocity inflation: “We’re doing so much better than 3 months ago, look our velocity has increased 20%!”. Unfortunately, after further investigation you determine the team is actually delivering the same amount via throughput + work breakdown structures.
7. Comparison from up above – Weaponizing velocity is no fun and can lead to a cross team comparison amongst teams + executives. Always make sure everyone understands the approaches to both techniques

Overall, both approaches have their pros and cons, and teams should choose the most appropriate metric based on their specific needs and context.

If you need assistance conducting appropriateness of each metrics, reach out to me or leave a comment below.