It's really unfortunate that velocity is called 'velocity'. I think that the name of this planning tool has contributed to a lot of misunderstanding. People seem to think that velocity is a measure of success and that it measures how well the Scrum team is doing in terms of pursuing its goals. But that is not the case. Velocity is a planning tool for the Scrum team and nothing more. Using velocity to measure the success of a Scrum team is like measuring a machine by a single cog in the wheel. The cog may be important, but it’s not the same as the value the machine produces.
First, what is velocity?
Velocity is a metric that represents the team's estimate (represented in terms of points) of how much effort, complexity, or uncertainty is associated with the sum of all Product Backlog items closed or completed during each Sprint. At the end of the Sprint, the team adds up the points for all completed Product Backlog items to determine their velocity for the Sprint.
Velocity is useful only as a way to forecast when will we get there. For example, if a team completes between 30-35 points per Sprint, then three Sprints from now they will probably have completed between 90 to 105 points-worth of work from the Product Backlog. This information can then be used to create a roadmap, or forecast, of what work might be delivered in the next three Sprints.
Velocity can be impacted by many different factors, such as:
Work complexity – Tasks were more complicated than expected.
Scope changes – Customer requirements shifted mid-sprint.
Team availability – Team members were on vacation or out sick.
Technical issues – Development environments were down or unstable.
Dependencies – Waiting on external teams or vendors.
Defects – Unexpected bugs required fixing.
Skill gaps – Team lacked expertise in certain areas.
Context switching – Team was pulled into unplanned work.
Stakeholder delays – Late feedback or approvals.
Process inefficiencies – Bottlenecks in reviews, testing, or deployment.
Estimate - Sometimes teams simply over or underestimate the work.
Why isn't velocity the same as success?
Judging a team based on their velocity is like measuring a restaurant’s success by the quality of their kitchen timers. Sure, the kitchen timer is helpful, but it's the taste and quality of the meal that matters.
Velocity is an arbitrary metric with significant uncertainty. Each team uses its own point system, meaning what one team considers a 5 could be a 13 to another, even within the same point system. Additionally, if a team over - or underestimates its work, its velocity can fluctuate dramatically—even if its actual development speed and quality remain unchanged.
When organizations use velocity to judge a team's value, they are really measuring how accurately the team sizes work rather than the impact their work is having on the customer. Worse, treating velocity as a performance metric can encourage teams to game the system—inflating estimates or prioritizing quantity over meaningful outcomes.
What Should We Measure Instead?
Success in Scrum should be measured by the outcomes a team delivers, not their ability to predict the future. Instead of focusing on velocity, ask questions like:
Are we improving customer outcomes?
Are we delivering valuable increments that solve real problems?
Are we continuously improving our ability to respond to change?
Are we building high-quality products that delight users?
And by the way, yes, teams should absolutely be able to create a believable roadmap or forecast for their work, and even meet hard deadlines when necessary, but velocity is just a tool for forecasting, so if predictability is what you are trying to measure then at least judge the forecast, not the tool.
Conclusion
Velocity is a tool for planning, not a measure of success. If you want to measure success in Scrum, look beyond how much work a team completes and focus on whether they are solving the right problems and improving customer outcomes. That’s the real measure of value.
Rebel Scrum is the host of the annual Scrum Day conference in Madison, Wisconsin. With speakers from Google to Space Force to Stanford, this is the best Agile conference there is!