Stop Using Velocity as a KPI: Why Pace ≠ Productivity

What?

I have had plenty of conversations this week (and on Linked In) regarding velocity and its use (or misuse). So much so, I wanted a more permanent place to summarize my point :)

Velocity—the measure of completed work per iteration—was never designed as a performance metric. Yet across organizations, it’s being used exactly that way. Managers track it on dashboards, stakeholders compare teams, and incentives are tied to how “fast” teams can move.

It’s a seductive idea. After all, velocity sounds like productivity. But it's not.

In Scrum, velocity is simply a team-specific measure of pace. It helps a team understand their own rhythm of delivery, observe patterns, and make smarter forecasts. When used internally, velocity can be a useful reflection point for how a team works. But when it becomes externally evaluated, it quickly becomes distorted.

Now What?

When metrics like velocity become KPIs, they get gamed. Not intentionally — it’s usually a natural response to pressure. Teams inflate estimates. They slice work thinner (which may not be a bad thing). They focus on completing "more" instead of delivering better. You end up with what I call "metric theatre" — an illusion of improvement, with no real gain in customer outcomes.

Consider this analogy.

Let’s say I’m driving from Dallas to Kansas City for an important meeting. To estimate my arrival time, I need to know:

• The distance I’m traveling
• The vehicle (or method) I’m using
• The route I’m taking
• And my pace — my velocity — measured in miles per hour

If a client insists I arrive by Noon, but my plan says I’ll leave at 6:00 AM and my pace suggests a 2:00 PM arrival, I have a decision to make. I can adjust the vehicle, leave earlier, or find a faster route. What I shouldn’t do is pretend I can get there by Noon just by saying I’m going faster. That doesn’t change physics — it only sets expectations I can’t meet.

Pushing teams to “increase velocity” has the same effect. It pressures them to look faster without actually solving the real constraints: unclear goals, bloated processes, or architectural limitations. Gaming the metric does not change the outcomes. In fact, it hides the problems we should be solving.

So What?

We need to reclaim velocity for what it really is: a planning and forecasting tool for the team. Used appropriately, it helps teams answer questions like:

• Are we improving our pace over time?
• What’s holding us back from delivering value sooner?
• How confident are we in our next release plan?

Velocity is for reflection, not judgment. When teams are trusted to self-manage and use their data responsibly, they build better internal awareness and continuous improvement. When that same data is used to compare, control, or reward, we get dysfunction, theatre, and missed outcomes.

It’s time to shift the conversation away from measurement-for-the-sake-of-it and back to value.