Velocity is one of the most used and most misused Scrum metrics. Understanding what it truly measures — and what it doesn't — is essential.
Scrum velocity measures the number of story points completed per sprint. It's an internal planning tool: if a team has a stable velocity of 40 points, they can confidently estimate how many sprints will be needed to deliver a given backlog. That's it. Velocity is not a productivity measure, not a quality indicator, not a comparison basis between teams.
The most common perversions: using velocity to evaluate individual performance, comparing velocity between different teams, or setting a velocity target the team must meet. These uses create counterproductive behaviors: inflating estimates to hit the target, artificially splitting stories, end-of-sprint rushing at the expense of quality. When you evaluate a team on its velocity, you get high velocity — not necessarily more delivered value.
Proper use: measure velocity over 5 to 6 sprints to get a stable average, use it for release planning only, and accompany it with quality indicators (test coverage, production bug rate, team satisfaction). If velocity drops, seek to understand why rather than demanding it rise. Often, short-term velocity decline accompanies long-term quality improvement — a trade-off only the team can honestly evaluate.