For additional background, you might also want to review two prior articles in the Agile Metrics series:

 

Good Uses of Team Velocity

A Guide for Sprint Planning

The first and best use of Velocity is as a planning tool for a Scrum Team. Velocity embodies the Extreme Programming (XP) concept of “Yesterday’s weather” that says you’ll get as much done today as you got done yesterday. For example, if the team completed 30 points last Sprint, 30 points the Sprint before, and 30 points before that, then it’s probably a good assumption that 30 points will fit into the next Sprint. I’ll talk more about how to do this later on.

Answering the Questions “When will we be done?” and “How much can we build by X?”

Velocity can be used, both by the team and the organization, to determine how much can be built in X time or when X amount of work will be done. It’s a simple application of looking at your historical Velocity and saying something like, “We did an average of 50 points per Sprint for the last six Sprints. The work remaining is currently 200 points, so it looks like we’ll be done in four more Sprints.”

Of course, there are several caveats around this. First and foremost is this will ONLY work with stable teams working from a relatively stable backlog. The more history (completed Sprints) you have, the better your forecast will be. If you have brand new teams, a brand new backlog, and no history, then all you’re doing is making a wild guess. I will go into more detail on how to use Velocity for capacity planning, as well as a better solution, in a future metrics blog.

 

Bad Uses of Team Velocity

“With great power there must also come great responsibility.” – Winston Churchill, 1906

Today we know this as the  Peter Parker Principle, after the famous words spoken by Spiderman’s dying uncle that bear a remarkable similarity to those of then Under-Secretary of Colonies Churchill (Note: Churchill didn’t say it first either, but let’s not dive down that rabbit hole).

Why do I start this section with this quote? Because Velocity may be one of the most misused metrics, even long before the dawn of Agile. I’m sure there is an ancient Egyptian hieroglyphic somewhere comparing how Baniti’s team moved rocks to the pyramid faster than Uthman’s team did. If we had a time machine to visit the construction site, we might find that Baniti’s team was moving stones to be used for the facing of the pyramid while Uthman’s team was moving the massive foundation stones.

 Scrum Team Velocity should never be used to do any of the following:

  • Compare one team against another: Velocity is unique to each stable team.
  • Measure team performance: You want stable, predictable velocity. Expecting it to go up all the time will drive false performance.
  • Measure only part of the work: Velocity is for the whole team and all the work your team is doing. 

 

How to Use Team Velocity As a Planning Tool

In my previous article on 4 Balanced KPIs to Measure Success, I briefly touched on using Velocity for planning and it is featured in our Agile Team Metrics Template. 

  1. Measure Velocity with both Points and Stories:  Operating on the balancing principle of self-supporting metrics, I always advise teams to track both the number of individual Stories (Product Backlog Items) completed as well as the more traditional Story Points when measuring Velocity.
    The logic here is that not all work is created equal and tracking two measures will give you a better gauge on the actual work. This also helps solve the problem created when the plan requires lots of small stories: Twenty 1-point stories actually require a lot more work than five 4-point stories (see Gary Weinberg, Quality Software Management).
  2. Modify Velocity with the Team’s Availability: Once you have a stable Velocity to plan against, then you want to apply forward looking modifiers to refine it even more. As I write this, we’re getting close to the United States’ holiday season. This means we’re going to start seeing Sprints impacted by things like Thanksgiving, Christmas, and New Years. Maybe last Sprint you did 100 points, that’s great. Only next Sprint you have a company holiday, and one of your team members is going to be in training for a week. You need to account for this.
    Once gain, you may benefit from using our     Agile Team Metrics Template to simplify your team planning.
  3. Use a Three Sprint Rolling Velocity: “Last sprint was horrible, with the network outage we only got half of what we planned done.” Life happens -it just does – which can make Yesterday’s Weather troublesome. The solution to this is to look at more than just yesterday’s weather. When determining a team’s velocity, I’ve found that three sprints (assuming two week Sprints) averages out the highs and lows of good and bad Sprints. I recommend applying this logic for all metrics and don’t really start leaning on a metric until you’ve got a solid trend.
  4. Talk about Unusual Spikes in Velocity: If your team’s velocity looks more like a roller coaster than a steady line, you want to talk about this in your retrospectives. Understanding variability is a key part of making Velocity work for your team.

 

“Choose Wisely”

Velocity is a powerful tool for team planning. If you choose to use it, proceed with caution. Velocity is not a performance metric, it is a source of foresight. 

If you’re ready to start using it, download our Agile Metrics Template Spreadsheet and the companion Team Availability Worksheet.