Value, Flow, Feedback

“Velocity” needs to die. Alternative measures?

Over the years, I’ve spent a lot of time with senior Executives of different organisations. Along the way, I’ve noticed a tendency for them to latch onto, and misuse, the concept of “Velocity”. Too often, I’ve heard someone say something along the lines of “We need to increase our Velocity.” Whilst the terminology here really doesn’t help – it sounds like an accelerator that you can put your foot on – this betrays a fundamental misunderstanding about a) what velocity is, and b) that velocity going up doesn’t give you what you want.

Firstly, what is Velocity? This is how Scrum Inc. defines Velocity:

“Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.”

Why is velocity a “key metric”? Well, as they go on to explain

“[Velocity} facilitates very accurate forecasting of how many stories a Team can do in a Sprint. (In Scrum this is called using Yesterday’s Weather.)”

So, in practice, velocity should be about understanding your capacity in order to prevent overloading of the team. Specifically, this is how Scrum forces the breaking down of large batches into small enough pieces for the team to work on that fit inside the specified time-box. Scrum encourages teams to a) deliver value early and often; b) optimise their end to end flow, and; c) use fast feedback to discover quality – all through the use of a small fixed time-box (typically 2 weeks or less). Teams have to fit any improvements they roll in to a product inside that small timeframe – and to produce a shippable increment by the end of the “sprint”.

As should be clear from this, velocity is a measure of a reasonable, sustainable batch size for a team. Wanting velocity to go up then is akin to wanting ever larger portion sizes at restaurants. Senior Execs wanting “more velocity” leads directly to the force-feeding of teams.

What generally happens in response, of course, is that by wanting velocity to go up is one or both of the following:

  1. Storypoint Inflation – This is the easiest way for the team to make their velocity go up. Since there is information asymmetry, they can simply inflate the value of the relative story points for a similar sized story and Bob’s your Mother’s Brother.
  2. Increase Work-In-Progress – Not only is this the opposite of what you want, it also tends to fail – it may work for two or maybe three sprints, but it’s generally not sustainable. You’re simply trying to squeeze in more work, an extra mouthful. This tends to reduce the level of collaboration in the team and also tends to have secondary effects in terms of poorer quality, both in the codebase and what the customer or user sees.

It’s worth pointing out that this also goes completely against the whole point of Scrum in the first place – which is a mechanism for iteratively improving a product by limiting work to fit inside a fixed timebox.  It also breaks your ability to do accurate forecasting using “yesterday’s weather”. No amount of proclaiming it to be blue skies, warm and sunny is going to make it happen!

And so, the term “velocity” is thoroughly broken if you consider the reasonable interpretation that people make when they hear it. Unfortunately, in trying to correct the thinking that velocity should go up, most teams lack an alternative measure for teams (and Execs) to use. There’s a risk, of course, that any alternative measure would be similarly prone to abuse or gaming. Nevertheless, I think we can do better than <nothing> as an alternative. So, what could we replace it with?

Well, first we should perhaps look at what we really mean by “agility”. I’ll share some thoughts on that in Part Two…