Skip to main content

Velocity is not the goal – working software is

Leadership often ask about velocity. "What is your velocity? How can you do better on velocity?"  

Sounds familiar, doesn’t it? But do you really know what velocity is, what it isn’t, and why it’s important?


Velocity is a measure for predictability, not productivity

Velocity can be measured as customer value delivered over time. It is a tool for the Product Owner to estimate how many sprints an epic will take to finish, so any tasks that don’t add value for the customer should not be measured.

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 one might assume that changes in velocity over time could be used to indicate overall shifts in productivity. 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 is no credible means of translating it into a normalized figure that can be used for meaningful comparison.

Why is Team A slower than Team B?

You can’t compare the velocity of one team to another’s.

For example, in the U.S., my shoe size is an eight; in India, it’s a five. There is definitely no change in the size of my actual foot from one country to another – the difference is how each country has chosen to assign their own scale of measurement for a shoe. Though eight is a bigger number than five, they both refer to exact same foot.

It’s the same in measuring velocity. What velocity means to team A can be completely different to team B. And there is a general consensus among Agilists that comparing velocity across teams is an anti-pattern and is best avoided, lest the overall productivity should suffer.

A further drawback of comparing team velocities, as mentioned by
Bob Hartman, the founder of “Agile for All,” 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. So in terms of velocity, a healthy velocity is a stable velocity.


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 creating big stories, 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 is waste.

To keep the velocity stable and keep your team on pace, define tasks that can be realistically completed within the sprint. Remember, working software is your primary measure of progress.

I would love to hear your thoughts about how your team uses velocity. Share on PegaBuzz!


About the author

Manjari is a true Agile practitioner who models the skills and mindset of agile, along with the responsibilities of being a Scrum Master. Manjari truly knows the difference between doing Agile and being Agile. As a Scrum Master, Manjari is the servant leader to her teams as well as to the larger organization. She is an expert at building high performing, self-organizing teams that deliver quality solutions with a naturally low operational overhead, whilst developing and maintaining a magnificent team spirit.

“I am a highly motivated team player who believes in getting things done whilst taking organizations on a value driven Agile journey. My philosophy is offering the right knowledge, at the right time, taught in the right way, so that individuals, teams and organization metabolize the knowledge for their best benefit.” 

A Certified Scrum Practitioner (CSP®) as well as a Certified Scrum Master (CSM®) from Scrum Alliance, Manjari has also achieved a Masters in Business Administration from ICFAI Business School, Bangalore, and is an active member of Universal Agile and the Scrum Community of Practice.

Manjari is a courageous and insightful decision maker who challenges traditional practices to push for  the best results for her teams. Her passion about human relationships, participatory and transformational learning, and self-organization, makes her a true asset.