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!