Velocity has been a core metric for Scrum based projects since its inception in 1995. Organisations like it because it’s a quantifiable figure, and one that can be measured over time.
But it has problems, it has a lot of problems.
“Then you should say what you mean,” the March Hare went on. “I do,” Alice hastily replied; “at least–at least I mean what I say–that’s the same thing, you know.”. “Not the same thing a bit!” said the Hatter. “You might just as well say that ‘I see what I eat’ is the same thing as ‘I eat what I see’!”. “You might just as well say,” added the March Hare, “that ‘I like what I get’ is the same thing as ‘I get what I like’!”. “You might just as well say,” added the Dormouse, who seemed to be talking in his sleep, “that ‘I breathe when I sleep’ is the same thing as ‘I sleep when I breathe’!”
Every team “means what they say”, and every team member means it too, that’s how a number is arrived at. The problem is, not every team means the same thing for the “same” number.
An example, team 1 has 10 members and together they have managed to calculate their velocity. Taken together that team has a velocity, duly communicated upwards, of 143. Great number, strong.
Team 2 has 5 members, some of them have managed to calculate their own velocity in addition to the team’s. A couple of the team are new though, and still finding their feet. That team has a velocity, again communicated upwards, of 47.
Is team 2 worse than team 1? Does team 2 need executive intervention? Does the team need broken apart and made in a different way?
Probably not, or at least, “you simply cannot tell”.
Team 1 and team 2 will probably be working against a different baseline, their interpretation of what goes into their velocity will be different and they’re already absorbing two new people. The last thing they currently need is more change.
Recommendation 1 – Never look at velocity in isolation
If team 1’s velocity last sprint was 150 and last month was 200 then suddenly you might start to think, “I need to put my attention on team 1, there’s something going on here”. A team’s velocity is something that develops over time and always needs to be considered against time, it’s the trend that gives the story, not the raw number.
Recommendation 2 – Don't compare teams
In our example the teams are different sizes, so comparing team 1 and team 2’s numbers directly is not a great thing to do. Although this was a deliberately obvious reason to not compare numbers the same is true for any two teams; the velocity of a team only relates to that team’s performance against itself. The number has literally no meaning outside of that context.
That’s a difficult concept to communicate outside of the agile management bubble, so in an organisation where reporting is king and something needs to be shown there are ways that you can communicate trend, without getting mired in the numbers
- Normalise every team’s number, so it’s working on the same scale. One example would be to take the velocity reported 2 sprints after the last reorganisation and make that “50”, that will then give the same starting point, and a scaling factor that helps to address the team size variable. If you want to be even more equitable then that factor would alter as the team size varies, but that’s starting to get complicated!
- Graph the teams’ velocities over time. Now that they are all working to the same scaled metric they could all go on one graph but I’ve always found that better conversations come when each team has their own graphs.
- Do not, under any circumstance, put numbers on the graph. Not scale on the axis, and no numbers available by hovering over data points. I’ll often screenshot the final graph and then put the picture into the report to avoid anyone surreptitiously “mining” the underlying data!
It’s the trend that’s important, not the number, and trends are best considered visually.
Recommendation 3 – Always allow for outliers and change
Having a number that tracks how the team is working across a two-week Sprint sounds like a wonderful way to measure performance. The reality is that in any given Sprint there will be all sorts of things that “happen” that mean you aren’t really measuring a full team across a full Sprint, ever:
- Bank/Public Holidays
- Annual Leave
- Company Meetings
- Customer Workshops (somehow these never end up in a Sprint planning session)
- The weather
- Global pandemics
The list goes on.
There are ways that you could try and represent these graphically, from putting in markers, using box plots, to trying to “normalise” them out. What works for you is the one that lets you have conversations that matter, with the people for whom it matters.
Velocity is an important metric, don’t get me wrong. It’s essential for individual team members to understand how long pieces of work take them, and so allow them to pull in the right amount of work at the right cadence. It’s not designed as an upwardly communicable performance metric.
“Who are YOU?” said the Caterpillar.
This was not an encouraging opening for a conversation. Alice replied, rather shyly, “I–I hardly know, sir, just at present– at least I know who I WAS when I got up this morning, but I think I must have been changed several times since then.”
If there are problems around velocity, then ideally we should be using a “better” metric. We should be using a metric that allows the non-IT people in the organisation to understand the speed at which features can be introduced, or problems solved. But that’s a whole other story.
“Well, now that we have seen each other,” said the Unicorn, “if you’ll believe in me, I’ll believe in you. Is that a bargain?”
We can help. If you want to gain better actionable insight on how your team is performing, or would like to discuss options to move your vision forward then please get in touch.
Classic Car Racing 02.jpg by Monaam Ben Fredi and distributed under the Creative Commons Attribution-Share Alike 4.0 International license. Cropped and Resized to fit.
