The map above illustrates a classic problem with the common use of 'velocity' as a metric.
It is also a great illustration of the assertion I made in my previous article: A Scrum Team Increases Their Velocity by Doing Less Work. The popularity of that article has surprised me as it's been syndicated by numerous e-zines and blogs. I think it struck a chord but my explanation was rather academic — the image above simplifies the argument. I'll explain.
Scenario
Your family travels each weekend to a nearby lake. You have identified at least these 3 possible routes. Which route is fastest?
That question is a trick. It's the trick which baffles many teams and managers.
- The shortest route is 67 kilometers and will take 68 minutes given known current traffic conditions.
- The longest route is 91 kilometers and will take 90 minutes. This route has the highest velocity!
It is obvious the shortest route is the best. It's the most direct and we'll arrive at our destination sooner. The trouble is, we'll have go a little slower.
If a manager is with us looking at the same map, if they understand the terrain the same way we do, when they can see the options before them I'm (almost) certain they'd agree to take the route with the lowest velocity. It is the most direct route. But if that manager does not understand the terrain, they are apt to demand the route with the highest velocity. After all, they want the team to go as fast as possible!
Please use this example when:
- You are explaining to stakeholders why TDD appears to be slower but is in fact more direct.
- You find yourself trying to justify building quality in.
- Your stakeholders are confused why technical debt needs to be repaid as soon as possible.
(Please share your own examples in the comments below. I'd love to hear your stories about how velocity is misused and how this article has helped you.)
Important End Note
Do make sure however that you are always focused on the most direct route. To use this example to justify any sort of gold-plating or pre-optimization is inappropriate.
***
This article is also published at scrum.works.
Closing
What’s your take on this? Is your experience similar to mine?
If you’re interested in learning more from me, visit my site and contact me to explore the opportunities for your organization.
Join me for a Scrum.org course: scrum.works/classes
And consider adding my recent book to your library: davidsabine.ca/phoenix