Your team estimates every story. You track how many points you complete each sprint. You calculate your velocity. You use that velocity to forecast future sprints.
It feels scientific. Rigorous. Data driven.
But here's the question nobody asks: Does tracking velocity actually make you ship better products?
Or are you just creating metrics that make you feel productive while actual productivity stays flat?
The Appeal of Velocity
Velocity promises predictability. If you know your team completes 30 points per sprint, you can forecast when work will be done.
It also promises accountability. If velocity drops, something's wrong. If it rises, you're improving.
It turns the messy, subjective work of software development into clean, objective numbers.
And people love numbers. They're concrete. Comparable. Easy to put in reports.
The Problem With Points
But here's what actually happens:
Points are arbitrary. A 5 for one team is an 8 for another. Even within the same team, a 5 in January might be a 3 in June as you get better at estimation.
Points incentivize the wrong behavior. Teams start optimizing for points instead of value. "Let's pick these three 5 pointers instead of that risky 8 pointer."
Points become a performance metric. Velocity was supposed to be a planning tool. But managers start asking "why was velocity lower this sprint?" Now it's a target. And Goodhart's Law kicks in: when a measure becomes a target, it ceases to be a good measure.
Estimation takes time. Planning poker. Debate. Refinement sessions. Hours every sprint spent assigning numbers to work.
The Velocity Trap
Here's the deeper issue: velocity optimizes for throughput, not outcomes.
A team can have high velocity and ship features nobody uses. They can close 40 points of low value work while ignoring the one high value thing that matters.
Velocity measures activity, not impact.
And in knowledge work, activity and impact are often inversely related. The most valuable work is often slow, uncertain, and hard to quantify.
What Teams Actually Do
In practice, teams game the system:
Inflate estimates: If velocity is a performance metric, make stories bigger so you hit your target more easily.
Cherry pick work: Take the easy, predictable stories. Avoid the hard, uncertain ones.
Split stories artificially: Break a 13 into three 5s so you can close more tickets.
Carry over partial work: Start a story at the end of a sprint so it "counts" toward next sprint's velocity.
None of this makes the product better. It just makes the metrics look good.
What Actually Matters
If velocity doesn't tell you much, what should you track instead?
Shipping cadence: Are you releasing regularly? Frequency of deployment is a better signal than story points completed.
Customer impact: Are users adopting the features you ship? Are key metrics moving?
Team health: Is morale good? Is turnover low? Happy teams ship better products than burned out ones.
Cycle time: How long from "start" to "done"? Faster cycle times mean faster feedback loops.
These are harder to quantify. They don't fit neatly in dashboards. But they actually correlate with success.
The Minimalist Alternative
Some teams skip story points entirely. They just:
- Break work into small, similar sized tasks
- Track how many tasks they complete per week
- Use that as a rough guide for capacity
No estimation. No velocity charts. Just throughput.
It's simpler, and often just as effective.
When Velocity Helps
To be fair, there are cases where velocity is useful:
Coordinating large teams: When multiple teams need to integrate, some forecasting helps.
Communicating with non technical stakeholders: Executives understand "we complete about 30 points per sprint" better than vague updates.
Historical analysis: Looking back at velocity trends can reveal process issues (like too many interrupts dragging down throughput).
But even in these cases, velocity is a rough approximation. Treat it as a hint, not a law.
The Honest Question
Here's what teams should ask: If we stopped tracking velocity, would we ship less?
For most teams, the answer is no. You'd ship about the same amount, with less overhead and less gaming.
Because the work is the work. Measuring it doesn't make it go faster.
Stop optimizing for points. Stop celebrating velocity increases. Stop treating Agile metrics like they're laws of physics.
Focus on shipping value. That's the only metric that actually matters.