Velocity for the layman
WARNING:This is a brain dump of an idea I’ve been playing around with, some confusion may occur!
As a ScrumMaster I often struggle to explain the concept of velocity to people, a critical concept to grasp to understand how to report on progress and capability. I often get these questions thrown at me:
- How many features can we complete in X weeks? or…
- How many bugs can one developer fix per day ?
- 1 developer = 1 story per sprint so 2 developers = 2 stories per sprint, right?
- 1 developer can fix one bug in 1 day, we could double our rate by doubling our people!! or…
- Adapt your average speed based on environmental conditions. Bad weather, day/night travelling, fatigue, additional rest stops, travelling through mountains? These all affect your average speed.
- Keep track of your average speed as you travel, this should give you an indicator of exactly what average you can maintain.
- Check what affects the distance between towns like road closures, alternate routes.
- Be ready to adapt to changing conditions, like accidents and sudden road closures.
Given the above you should be able to accurately predict when you will arrive at your goal. As a bonus you can also work backwards. Given your need to arrive at a particular time, you can sum up the total distance and divide it by the time you have and this should give you the speed you should try to average.
So, to bring it back to velocity, you average travel time can be equated to the teams average velocity (or capability). Stops are user stories/bugs and distance between cities is the effort of doing the story. Conditions of road, road closures, mountain travelling, predicted bad weather etc is your complexity.
Here’s hoping this analogy makes sense, if it doesn’t please let me know. I still think it’s missing something though so I may add to it at some point…