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.