Velocity is the sum of story points completed in a sprint. It is a historical measurement for forecasting — not a performance metric, not a goal, not a benchmark to compare teams against.
"Velocity is typically calculated with story points used to estimate backlog items. It's used to reliably forecast how much work can be accepted into an iteration." — IIBA Agile Extension
Used correctly, velocity helps the team answer one question: "At this pace, when will the backlog be done?" After three to five sprints, a stable velocity gives you a reasonable planning horizon. That's its entire purpose.
Used incorrectly, velocity becomes a management pressure lever — and that's where it breaks:
- Teams inflate estimates to hit "velocity targets"
- Comparing velocities across teams is meaningless (each team's points are on a different scale)
- "Velocity dropped" triggers blame instead of diagnosis
The right response to a velocity drop is: "What changed?" — not "work faster." It might be that the team took on debt and is now moving slower because of it. It might be that a key person was out. It might be that the stories were larger than average this sprint. Each of these calls for a different response.
I've worked on teams where velocity was tracked on a dashboard and shown to clients. The effect was predictable: teams started gaming the estimates, which made the velocity stable but the forecasting useless.
Exam tip: The Scrum Master's job when velocity is inconsistent is to identify impediments to flow — not to push the team to do more. PSPO and PSM scenarios frequently test this distinction.