Scrum, velocity, and driving down the motorway the wrong way

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.

I’ll be talking about this, and a lot more, at the Product Owner Survival Camp mini-conference in Vienna in October.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your User Stories. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

Product Owner Survival Camp

Conference talks and workshops

3 thoughts on “Scrum, velocity, and driving down the motorway the wrong way

  1. burndown charts are part of the standard SCRUM and show visually the progress. If not that, so what do we measure then?

  2. @Azeem – burndowns are not part of Scrum since 2009. Try to look for it in latest Scrum guide.
    It is just some extra tool not mandatory.

    IMO velocity is not a problem – but velocity mesured in estated points is.

    If you want to measure progress of your team start measure delivered bussines value or ROI. Remember that Product Owner is part of Scrum Team.

  3. There are some good arguments in your post. Like every metrics the problem emerges in how you use it.
    Velocity can be helpful for 2 things:
    – estimate when we can release
    – see if the team runs in a sustainable pace

    According that very few people are taking the PO course, it’s obviously embarrassing to see the bloody behavior you described.

    In the meantime, and according that mother nature do not like emptiness, we are missing TechDeb counter measures to keep the balance right.

    By now, with a lot of empathy, I believe that the change process is driven by keen people aware how to use gracefully rapidscrum metrics to protect the team from management expectations.

    Now we know that the lessons learned of failures (MySpace or Chrysler) enforce the emergence of new skills like XP.

    According to that, the real question is should I use a Ferrari to drive in the traffic jam?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>