Velocity isn't evil

Man, Velocity cannot catch a break at the moment can it? The amount of posts that are giving it an absolute kicking and suggesting it be dropped is astounding to me. Sounds the same as teams abandoning Scrum because "Scrum doesn't work"?

Is this not an example of where we need to educate people on what the velocity is and how we use it? To me it seems to be the perfect opportunity to showcase its capabilities and highlight the shortcomings if abused. Don’t get me wrong, I’m not saying story pointing is the be all and end all when it comes to sizing backlog items, but velocity data is a big benefit if you do.

There is a common theme in the posts that I’ve seen: we all seem to know how not to use it and the damage is can cause. As such I am not going to dwell on that, instead focussing on ways that I use velocity data with my teams and how it helps us. It’s a powerful set of data, which inevitably means I’ll wheel out the old “with great power comes great responsibility” adage.

So then...what can we use velocity for…

Helping us predict what we might get done next sprint

I know, I know. This is what is was envisaged for and you knew this one. Based on your past performance you can use this data to inform you how much work you maybe able to do in the following sprint.

Best way to do this? Arguable I think is the best answer I can give. I like to use a combination of rolling average velocity (based on the past 3 sprints) and Velocity Range. The latter of which requires at least 6 sprints of data, and gets more accurate as time progresses with more data being collated. I love it as it gives you an upper and lower bound with a median, looks a bit like this when charted (over time):

The team can use this information and their known capacity for the following sprint as a guide to how much they can potentially do in the next sprint.

Helping us predict when something might get done

Not limited to just looking at the next sprint, we can also use velocity to help give stakeholders an idea of when a product backlog item maybe done (which is another reason why the range is useful - you’ll be able to tell people “we think it will take between x and y”).

Using your velocity information in conjunction with something like Blink Estimation and you can forecast with a pretty startling accuracy. Great for roadmapping (especially if you do this on a quarterly basis).

Obviously if your velocity range has a variance of, say, 70%, then you’re pretty much guaranteed to get your work done in the range that you offer. This is bad. But is a nice segue in to…

Helping us discover how predictable we are

Ultimately we want to be reasonably predictable so we can build trust with our stakeholders. I say this because we may need to accept that some people aren't as far along the transformation journey that we are; they are likely coming from years and years of working practices that value output over outcomes, so let us work with them.

Eurgh. Stakeholders. It’s such a crap term, it’s almost a way of dehumanising them - they’re our colleagues, and if we’re not predictable then we are potentially having a direct impact on a colleagues life in terms of stress levels they have. That’s not cool. So not only does being unpredictable affect us, it affects others too.

The velocity data we collect is incredibly useful for generating insight here and also highlights why you can’t use “Rolling Average” on it’s own as it can hide this view. A lot of tools out there give us a velocity history chart and this, in conjunction with the rolling average velocity and the velocity range help us paint a picture.

What the chart tells you (but the rolling average hides) is that you could be in a situation where you ship 15 points one sprint, and none the next. If you did this repeatedly then you’d have a rolling average 7.5 points over your sprint….but you don’t. Not really.

If your sprint length was 2 weeks, using the above scenario, it could take a month before features were actually shipped, although your rolling average would make it seem that if you pulled something in to a sprint (and your commitment was around 20 points) then it would be shipped within 2 weeks. And don’t give me that weak sauce argument about the distinction of a “potentially shippable increment” - with modern CI/CD pipelines we can ship as soon as something is ready. Done can mean “live”.

Velocity range is, in my opinion, the best indicator of how predictable you are; if your range is huge (50% either side of the median means your whole range is 100% - meaning something could possibly take twice as long - this is an absolute train wreck when blink estimating as you’ve got no confidence...therefore you can’t use it...which means you can’t reap the rewards). Recording the data from sprint to sprint and charting it means you can see how you’re progressing towards lessening the variance.

Mike Cohn’s article (linked to above) explains how the range is calculated (in detail). For this article I will give a very basic summary: once you get above 8 sprints the calculation starts dropping the outliers in the data - so that sprint where you delivered 0 points (or the one when you delivered 167) will stop corrupting your data, thus tightening your range, giving your a truer representation.

An aside - I’ve yet to work with a team who can game the variance figure. Usually the process of trying to actually ends up in a genuinely smaller range.

Illustrating the impact of changes in the team

My personal favourite. One of the biggest perks of collating data to get your velocity is that you can show the impact of changing team members with relative ease.

Be it adding a new team member, swapping someone out, reducing team size - all of that can be captured and you can then see how big an impact it made on your rate of delivery, as well as how long it lasted.

Check it out - this is my current team:

Every label is someone coming or going from the team (including before I joined), the solid red line is the trend line for the velocity.

The team has always been the same size and the people coming and going have affected every role we have in it (apart from our CMS editor and QA Analyst). The Scrum Master changed (when I joined), the devs have all changed, the UX unicorns, BA, PO. And the changes were close. Too close for us to recover, far too close for us to have any sort of predictability. It’s broadly agreed that it can take between 3 and 6 sprints for a team to find their new rhythm based on a change to the team and my experience shows this to be true.

That’s born out by the charts - below are two of the charts I’ve posted above (apologies for the repetition, I couldn't think of a better way to do it), but presented together. This is my point - I suggest that you shouldn’t just use one of them, you need to look at the data in multiple ways for it to be truly useful. And it is useful - there’s a lot of value in velocity data.

A sticking point

This might be contentious: If you have any changes to the team, should you bin all previous velocity data? Is it reliable anymore - the historical data was based on a different combination of people working together, so is it valid?

Are there criteria where you would keep it (only one person changes in the team as an example)? What would you do in my situation where someone has changed in every other sprint (on average) for a while?

If you bin the data when you make a change to the team makeup does this really drive home the impact of making team changes? I think it could. It opens you up to being seen as dogmatic, but this could the sort of thing that being dogmatic about is the right thing to do?

Clearly I’m conflicted on this bit - let me know your thoughts on that as well as anything else in the article.

Why is this useful information?

I realise I haven't said much on why you may want this data yet, just how you can use it.

It's a really simple answer - the team can use this data to help them uncover areas which need to be improved. Velocity is a useful tool in supporting the "inspect and adapt" mindset. Like Scrum, velocity won't fix any of your problems, but it will help lift the rug and shine a light (to butcher Tobias Mayer's analogy) on the fact that there maybe an issue. OR if someone has identified an issue which they think is critical, it could be used to see if there genuinely is an impact.