Why Velocity Metrics Mislead Product Leaders
Story points and sprint velocity feel like rigorous measurement. They are actually a proxy that obscures more than it reveals — and building strategy around them leads to predictable failures.
Velocity is one of the most widely used and least understood metrics in product development.
In theory, it measures how much work a team completes per sprint. In practice, it measures how many story points a team assigns to the work it completes per sprint — which is a very different thing.
The conflation of these two things leads product leaders to make systematically bad decisions. Understanding why requires looking at what velocity is actually measuring, what it is not measuring, and what you should be tracking instead.
What Story Points Measure
Story points measure perceived complexity relative to other work. They are not units of time. They are not units of business value. They are a rough indicator of effort calibrated within a specific team, against a specific codebase, at a specific moment in time.
This means velocity numbers are non-transferable. A team that averages 40 points per sprint is not “faster” than a team that averages 20 points — they may just be using a different calibration scale. Comparing velocities across teams is meaningless at best and actively misleading at worst.
Within a single team over time, velocity can be a useful signal that something has changed — a new engineer joined, the codebase got harder to work in, interruptions increased. But even here, the signal is noisy and contextually dependent.
How Product Leaders Misuse Velocity
The misuse pattern I see most often: a product leader treats velocity as a production forecast and uses it to make promises.
“The team does 40 points per sprint. This feature is 80 points. We can commit to a 6-week delivery.”
This reasoning fails for several reasons.
Story point estimates are not reliable forecasts of time. The standard deviation on task estimates is enormous, even for experienced teams. Research on software project estimation consistently shows that developers underestimate complexity, especially for novel work. The average software estimate has an error rate that makes precise time-based commitments from point estimates fundamentally unreliable.
Velocity is a trailing average of past performance, not a prediction of future performance. A team’s velocity in the last quarter reflects the type and complexity of work they did then. It says very little about what they will do with new work, new architectural challenges, or work in a domain they have not touched before.
Optimizing for velocity incentivizes gaming. When teams know their velocity is being watched as a performance metric, they learn to inflate estimates. A three-point ticket becomes a five-point ticket. Total points go up. Work completed stays the same. Stakeholders see the number they want to see. Everyone is slightly more dishonest.
The “Velocity Trap” in Action
Here is how the velocity trap plays out in organizations over a 12-18 month period:
Month 1-3: A new product leader introduces velocity as the primary planning metric. Teams are told to be consistent with their estimations. Velocity averages are established.
Month 4-6: Planning happens based on velocity projections. Deadlines are set. Commitments are made to stakeholders based on point counts.
Month 7-9: The team hits technical complexity that was underestimated. Velocity drops. The product leader does not have a model for why — was it scope change? Technical debt? People issues? The metric does not distinguish. Pressure increases.
Month 10-12: The team learns to manage the number. Estimates increase. Scope is quietly reduced to hit the velocity target. Technical quality erodes because time is being spent on maintaining the metric rather than building the product.
Month 13-18: Leadership loses confidence in planning. Engineers lose respect for the process. The metric that was supposed to create predictability has created a performance theater instead.
What to Track Instead
Velocity has some value as a team-internal calibration tool, but it should not be the primary metric for product leaders. Here are more useful measures:
Cycle time: How long does it take for a unit of work to go from “in progress” to “done”? Cycle time, especially broken down by type of work, gives you information about where the process is slow. It is less gameable than velocity because it is tied to calendar time.
Throughput: How many items of work get completed per sprint — regardless of their point value? Throughput penalizes the “score inflation” problem. If a team is completing 12 items per sprint and drops to 8, something has changed. Point values do not obfuscate this.
Unplanned work percentage: What fraction of each sprint consists of work that was not planned at the start? High unplanned work is a leading indicator of instability — reactive maintenance, unclear requirements, or an environment where planning is not predictive.
Deployment frequency and change failure rate: DORA metrics (from the DevOps Research and Assessment framework) track how often a team deploys and what percentage of deployments cause incidents. These connect engineering performance to product reliability in ways that velocity completely ignores.
Team-reported confidence: At the start of each sprint, ask the team: “How confident are you that you will complete the planned work?” A simple 1-10 scale, tracked over time, is a surprisingly strong leading indicator of delivery performance.
The Underlying Issue
The appeal of velocity is that it seems objective. It converts the messy, unpredictable work of software development into a number, and numbers feel manageable.
But the number is not actually objective. It is a social construction — the output of a team’s internal negotiation about how complex work feels — wrapped in the appearance of measurement. Using it as the basis for strategic commitments and leadership performance assessment is like measuring organizational health by counting the number of smiles per meeting. You are measuring something. You are not measuring what you think you are measuring.
The best product leaders are comfortable with the irreducible uncertainty of software development. They do not try to eliminate it by finding better metrics. They develop judgment about team capacity and delivery risk through direct engagement with the work — reading code, attending sprint reviews, understanding the technical landscape — not through dashboard numbers.
Velocity can be one input. It should never be the primary lens.