Velocity vs Throughput: Why These Metrics Are Not the Same

If you’ve ever heard “Our velocity dropped” and “Our throughput is up” in the same meeting — you’re not alone. These two metrics often get mixed together, compared incorrectly, or used in ways that create bad incentives.

This guide explains what velocity and throughput actually measure, why they’re different, and how to use both without turning metrics into a guessing game.

Quick Definitions

What is Velocity?

Velocity is a Scrum metric that shows how many story points a team completes per sprint (on average). It’s mainly used for:

• sprint planning and capacity forecasting
• understanding what a team can typically deliver in a sprint
• stabilizing commitments over time

Important: Velocity is team-specific. Story points are relative, not universal.

What is Throughput?

Throughput is a flow metric that shows how many work items are completed in a time period (e.g., “12 tickets per week”). It’s used for:

• forecasting delivery based on historical completion rates
• understanding system capacity and flow
• spotting overload and bottlenecks

Throughput is measured in items completed — not points.

Velocity vs Throughput: The Core Differences

1) Units of Measure

• Velocity: points / sprint
• Throughput: items / time period

Because points are relative and items are countable, the metrics behave very differently.

2) Context

• Velocity is typically tied to Scrum and sprint-based planning.
• Throughput can be used in Scrum, Kanban, or any workflow where “done” can be counted over time.

3) Comparability

You should not compare velocity across teams. One team’s “5 points” might be another team’s “2 points.”

Throughput can be more comparable if your work items are similarly sized and defined — but it still needs context (e.g., “what counts as an item?”).

4) How Easy It Is to Game

Velocity can be manipulated if teams inflate story points or split work unnaturally.

Throughput can also be manipulated by slicing work into tiny tickets — but it’s often easier to detect if you’re also watching lead time and carryover.

A Simple Example

Two teams complete the same outcomes in a sprint:

• Team A: 40 points completed
• Team B: 20 points completed

Did Team A do twice as much work? Not necessarily. Their point scale might be different.

Now look at throughput:

• Team A: 12 items completed
• Team B: 11 items completed

That’s much closer — but it still depends on whether “items” are similar (a one-line bug fix vs a major feature shouldn’t be treated the same).

When You Should Use Velocity

Velocity is useful when your team:

• works in stable sprint cycles
• estimates consistently in story points
• uses velocity to improve planning — not to judge performance

Use velocity for: sprint planning, forecasting within one team, and learning whether your commitments are realistic.

When You Should Use Throughput

Throughput is useful when you want a clearer signal of delivery pace across time. It works best when your team can:

• define “done” clearly
• count completed items consistently
• review trends weekly or sprint-by-sprint

Use throughput for: forecasting delivery volume, identifying overload patterns, and validating improvement efforts.

The Best Approach: Track Both (But Don’t Confuse Them)

If you run Scrum, a strong practical combo is:

• Velocity → planning confidence (points per sprint)
• Throughput → delivery pace (items completed per sprint/week)

This helps you avoid the classic trap where “velocity looks fine” but work still feels stuck, overloaded, or unpredictable.

Common Mistakes to Avoid

• Comparing velocity across teams: it’s not a fair benchmark.
• Using velocity as a performance KPI: it encourages point inflation.
• Converting points to hours: it defeats the purpose of relative estimation.
• Ignoring work size: throughput alone can mislead if items vary wildly.
• Measuring without improving: metrics matter most when they drive better decisions.

How to Improve the Metric That Matters

If your velocity is unstable or your throughput isn’t improving, the solution is rarely “estimate harder.” It’s usually about improving the system: reducing overload, improving clarity, and building a culture of continuous improvement.

Recommended improvement-focused reading:

• Kaizen vs Innovation: Why Continuous Beats Occasional
• What Is Kaizen? A Beginner’s Guide to Continuous Improvement
• Lean Culture vs Lean Tools: What Actually Drives Change
• The Complete Guide to Lean Transformation
• Kaizen Metrics: What You Should Track (and Ignore)

Watch Out for the Real Productivity Killers

If your throughput is lower than expected, it’s often not because people are lazy — it’s because work is fragmented and attention is constantly pulled in multiple directions.

• Task Switching: The Productivity Killer in Disguise
• The Hidden Cost of Multitasking (Lean Perspective)

Final Thoughts

Velocity helps you plan inside Scrum. Throughput helps you understand delivery pace and flow. They’re both useful — but they answer different questions.

Use the right metric for the right decision, and you’ll improve outcomes without accidentally training your team to “hit the number” instead of delivering value.