Some project managers track sprint velocity like a scoreboard. More points this sprint than last sprint signals improvement. Fewer points means the team is struggling. It is clean, simple, and wrong.
Velocity measures work output relative to a team-specific unit that shifts with time, team composition, and work type. Using it as a performance metric creates incentives that corrupt the data you are trying to collect.
What Velocity Actually Measures
Story points are relative estimates, not objective units. A 5-point story last quarter and a 5-point story this quarter are not the same amount of effort. They are the same relative complexity compared to other stories estimated at the same time by the same people using the same baseline.
When team composition changes, the unit changes. A new developer calibrates differently than the person they replaced. Two sprints later, velocity looks different even if nothing else has changed. When work type changes, the numbers shift. Maintenance sprints typically produce lower velocity than feature sprints, even when the team works equally hard and delivers more value.
Velocity measures how much work your team completed relative to its own past performance, using a unit that drifts with context. That is useful for capacity planning within a stable team working on consistent types of work. It is not useful for comparing teams, judging individual performance, or setting targets.
The Management Trap
Using velocity as a performance metric creates incentives that corrupt the data. Teams start padding estimates to hit higher numbers. Scope gets cut to improve the ratio. Honest conversation about process problems gets replaced by scorekeeping.
None of that serves the project. It serves the metric.
This happens more often than teams admit. A sprint goes sideways because requirements were unclear. The team still delivers something useful. Velocity drops. Management interprets the drop as underperformance. The next sprint, the team sandbags estimates to protect their numbers. Now your velocity data is useless for planning, which was the only legitimate reason to track it in the first place.
Who Is Affected
If you are a scrum master or project manager, you are probably already caught in this loop. You report velocity to stakeholders who want to see improvement. You pressure teams to hit higher numbers. Teams respond by gaming the estimates. Everyone ends up with data that looks good and means nothing.
If you are a team lead or developer, you feel the pressure when velocity drops. You know it might reflect a difficult sprint, a complex problem, or a team member who left. The number does not capture any of that. Your performance review might still hinge on it.
If you are a stakeholder, you want to know if the project is on track. Velocity cannot tell you that. It can tell you how much work the team completed relative to itself last sprint, which is a very narrow slice of the picture.
Our Analysis: What to Use Instead
If you need a performance metric, measure outcomes, not output. Did the team deliver what they committed to? Did the stakeholders get what they needed? Did the product improve in ways that matter to users?
Those questions are harder to answer than "how many points did we finish," but they tell you what you actually want to know.
Velocity has legitimate uses. You can use it to forecast capacity for the next sprint. You can use it to spot trends over many sprints, as long as you account for changes in team composition and work type. You can use it to identify when a team is consistently overcommitting or undercommitting.
What you cannot do is use it as a scorecard for individual or team performance without creating problems.
A Practical Example
Say you are planning the next quarter. You have historical velocity data showing an average throughput over the last several sprints. Some sprints came in lower because a senior developer was out on leave. Others hit higher because the work was unusually straightforward.
A naive forecast would average all sprints and give you a capacity that does not account for context. A better forecast would strip out outlier sprints and give you something closer to realistic expectations. But the real answer depends on what you expect next quarter. Are you doing maintenance? New features? Adding a new team member? The historical data helps you ask better questions, not answer them directly.
What to Watch Next
Track velocity for capacity planning. Report it to stakeholders if they insist, but frame it correctly. Make sure they understand it is a team-specific, context-dependent measure, not an industry standard like revenue or defect rate.
If your organization uses velocity for performance management, start a conversation about alternative metrics. Come prepared with options: outcome delivery, stakeholder satisfaction, team health indicators. These are harder to measure, but they measure something worth measuring.
Your team deserves better than a number that was never designed to measure what you are asking it to measure.
Key takeaways
- Velocity measures relative output, not absolute performance
- Story points shift with team composition and work type
- Using velocity as a scorecard corrupts the data
- Measure outcomes, not output, for performance assessment
- Come to stakeholders with alternative metrics if velocity is being misused
Frequently asked questions
Is velocity useful at all?
Yes, for capacity planning within a stable team working on consistent types of work. It helps you ask better questions about the next sprint.
What should I use instead of velocity for team performance?
Outcome delivery, stakeholder satisfaction, and team health metrics give you a clearer picture of whether a team is actually performing well.
How do I explain to stakeholders why velocity is not a performance metric?
Use the unit comparison. Points are like clothing sizes—useful for relative comparison within a set, not for absolute measurement across different sets.
Can I compare velocity across teams?
No. Each team calibrates story points differently. A team that consistently scores lower is not performing worse than a team that scores higher if their work is equally valuable.
What should I do if my organization already uses velocity for performance reviews?
Start documenting how velocity fluctuates with context changes. Present alternatives like outcome delivery or team health metrics to decision-makers who have the authority to change the system.