Many Scrum Teams make use of Velocity. In the right hands, it's an incredibly useful measure. In the wrong hands, it can become a tool of obfuscation and even oppression. Here's how:
Velocity as a Measure
In the Professional Scrum Master course, there's an exercise that asks students what a desirable Velocity is. They work on this exercise in their teams and the answers they produce are always insightful. And yet they usually miss the best answer. Perhaps because it's taken for granted? But to my mind, the most desirable thing about Velocity is that it tell the truth. I need it to be honest and transparent.
As you may know, Scrum is based on empirical process control. Empiricism depends upon transparency, inspection and adaptation. To make useful adaptations, we must first have inspected a transparent artifact. In this article, Velocity is the artifact. It represents the amount of work a Scrum Team gets done within a Sprint. With a transparent Velocity we can:
- Create usable forecasts and plans
- Measure the results of process improvements
- Assess the effects of factors on team performance
When used as a measure, Velocity is useful. Very useful.
Velocity as a Target
Perhaps its the beautiful simplicity of the measure that attracts some people to use it as a target? If you've ever heard phrases like the following, it's possible that Velocity has become a target:
- I need an extra 10% Velocity
- Is Velocity increasing?
- What is the Velocity of Team A vs. Team B?
This list is not exhaustive. You may well have come across others.
The list items are anachronistic. A throwback to an older style of management perhaps. A place where phrases like 'drive delivery', 'stretch goals', and 'push performance' fester and thrive.
The trouble is, that once a measure becomes a target, it gets gamed. As Goodhart's Law puts it:
When a measure becomes a target, it ceases to be a good measure.
Don't get me wrong. Wanting to improve performance is a good thing. However, bending a measure to give a false impression of improved performance is wrong. Imagine it this way:
Driving the Point Home
The speed limit on motorways in the UK is 70mph. The speedometer in your car is a measure to assess your current speed. It works best when it is honest. To avoid getting a fine for speeding, we inspect our speed and adapt the pressure we apply to the accelerator to stay below the speed limit.
Now imagine you want to stay within the legal speed target. So, you ask a mechanic to bend the needle on your speedometer such that it always read 20mph slower than you were actually travelling. Now, you can travel on the motorway at up to 90mph safe in the knowledge that your speedometer will stay within the target.
Of course, it won't save you from a speeding ticket. And you won't be able to forecast when you'll arrive at your destination. And any adaptations you make by pressing the accelerator are giving you a false outcome. But hey! You can kid yourself that you're travelling at 70mph, being safe and legal, when actually you're doing 90mph, being dangerous and driving illegally.
To continue with the analogy: In Scrum, the accelerator is the Sprint Retrospective and Velocity is the speedometer. The Sprint Retrospective is where we press adaptations. Velocity is where we measure the outcome on performance.
Summary
To borrow from Rowan Atkinson in Blackadder II:
Using Velocity as a target is like a broken pencil. Pointless.
Velocity. Terrific Measure. Terrible Target