Get certified - Transform your world of work today


Velocity Is Not the Goal

8 March 2017

Manjari Kumar

How often does your leadership ask you, "What is your velocity? How can you do better on velocity?" Sounds familiar, doesn’t it?

Velocity is a measure for predictability, not productivity

Agile development does not necessarily lend itself to the kinds of dashboards and reports beloved by managers. The few metrics it produces make little sense outside of the context of team planning. Given this shortage of usable information, it can be tempting to repurpose velocity as a measure of productivity. After all, it’s a measure of team capacity, so it follows that changes over time could be used to indicate overall shifts in productivity — doesn't it? The problem with this approach is that velocity is a planning tool rather than a specific measurement. It’s an estimate of relative capacity that tends to change over time, and these changes don’t necessarily indicate a shift in productivity. It’s also an arbitrary measure that varies wildly between teams. There’s no credible means of translating it into a normalized figure that can be used for meaningful comparison.

Metrics are not a bad thing, but the wrong ones are.


Teams tend to pad up their velocity, which does not add any customer value. Velocity is a tool for the PO to estimate how many sprints an epic will take to finish, so anything that doesn’t add value should not be given points.

Why is Team A slower than Team B?

When I was in the U.S., my shoe size was 8. When I relocated to India, the shoe size that fit me is 5. There is definitely no change in the size of my foot, but the difference is how each country has chosen to put a number on a given shoe size. Though 8 is a bigger number than 5, they both refer to exact same foot size. My point is that you can’t compare the velocity of one team to another’s, as what "1" means to team A can be 10 to team B.

Among Agilists there is a general consensus that comparing velocity across teams is an anti-pattern and is best avoided, lest the overall productivity should suffer.

A further drawback, as mentioned by Bob Hartman, of comparing team velocities is that the teams would start changing their story point scale so that their velocity looks better in a comparison.

What is a healthy velocity?

Sustainable pace in Scrum is important. It means that a team’s capacity to deliver a certain amount of work should stabilize and become more and more predictable.

Healthy velocity is the stable one . . .



And not . . .



Velocity is not speed

Speed is a measure of distance over time. Velocity is a measure of displacement over time. Velocity is a vector: It has direction.

Increasing speed can increase velocity. But it can just as easily decrease it.

Good speed is asking: How can I make this two-day task into two one-day tasks?

Bad speed is rushing, burning out, and piling on technical debt. It’s building features that nobody uses, that your customers don’t care about and that don’t add value to your business. It’s prioritizing business needs over customer needs. It’s waste.


Again, Agile is a framework, and a team can tailor it to their needs. I would love to hear your thoughts about how your team uses velocity.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (5 ratings)


James McDonagh, CSP,CSM, 3/8/2017 3:10:33 AM
Good article. The wider topic of metrics is a thorny one alone, but velocity is definitely seized upon too often by ill-informed managers.
Manjari Kumar, CSP,CSM, 3/8/2017 10:13:21 PM
Sure metrics should not be abused else they ceases to be a good measure.
Keith Brewer, CSM,CSPO, 3/10/2017 2:02:42 PM
Great article!
Rumesh Wijetunge, CSP,CSM,CSPO, 3/17/2017 3:18:50 AM
Good article.
Our team uses velocity simply as a measure of progress and a relative yardstick based on which future sprint goals are set. Along with a story point estimate we also do a capacity planning on how many hours in total the team would be available during a given sprint. So like you've said its used just as a point of reference to keep track of progress made by calculating the number of story points burnt.
Manjunatha Gopalakrishna, CSM, 4/3/2017 5:00:21 AM
Nice to see this here @Manjari! Velocity, Estimation are used for predictability and should be kept at that!
Bhargav Ram Vedula, CSP,CSM, 4/21/2017 12:41:19 PM
Neatly articulated Manjari.
The average across 5 sprints helps business to get fine understanding on how much work can be completed by a particular team.
More focus should be to achieve the sprint goal and reduce the cycle time.
Shivkumar Sankaran, CSP,CSM, 6/14/2017 5:44:43 PM
There is a bit of "Coaching the management" involved here as well. As long as the team is able to show the progress in terms of working software and value delivered and the Product Owner is able to voice out the alignment of the value delivered to the overall product roadmap, organizations will start using velocity more as a planning tool than for management reporting.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up