Teams new to Scrum are often obsessed about story points and velocity. Burndown charts and burnup charts hang from walls to convince both the team and the management of how well they’re doing, and improved velocity seems to be one of the key selling points for Scrum consulting gigs. A nice example of that is the Scrum Shock Therapy page. Using lots of numbers, percentages and impressive increases in velocity, readers are convinced about the advantage of the Shock Therapy approach that lead to a team becoming 400% hyper-productive. Knowing nothing else about that, I’m sure that managers at large would like to have such an improvement in their department, and that many delivery teams would be quite happy to get to that point. On the other hand, consider that the company in question was actually MySpace, once a market leader and now effectively an also-ran social network, far on the path to irrelevance. Would you still like to be them?

Velocity is in essence a negative metric - it can tell you that something is wrong, but not that something is good. Blood pressure is a good example of a negative metric: high blood pressure is a clear signal that something is wrong, but a normal blood pressure does not give anyone enough information to conclude anything about someone’s health. Even worse, the easiest way to instantly reduce high blood pressure would be to chop someone’s head off, but it would be a far stretch to claim that the patient would be healthier. Many managers new to Scrum, and metric-obsessed Scrum masters, do exactly that to their teams by slavishly using velocity as the primary measure of progress.

Imagine you’re in a car, driving on the motorway. If your velocity is below 20-30 MPH, you know that something is wrong. There might be lots of causes for that, and you don’t even have to know the root cause to decide on corrective action - maybe phone ahead to tell someone you’ll be late, or look for an alternative route. Using velocity for that kind of process control is great. If, on the other hand, the car is moving at 60-70 MPH, that piece of information stops being so relevant. There are much more important questions: Are you on the right route? Do you have enough petrol to reach the destination? At that point, improving velocity at the expense of other things would be unwise, as you might fail to make the right turn or be flexible when the road ahead suddenly gets blocked. Similarly, once a team has a reasonably good velocity, it’s time to start looking at some other things such as: Are we building the right software? Do we have enough work in the pipeline to continue working? Do we have enough resources to cover the road ahead? Are we flexible enough to cope with the changes that our business might want from us?

Velocity is a nice metric for internal process monitoring, so you can spot problems early. But beware of using a negative metric such as velocity as your primary measure of success, it leads down the path of false hyperproductivity and a warm feeling that you’re doing something good when in fact you might be driving the wrong way down a motorway, with a truck heading straight at you.