How to measure and use the velocity of Agile teams

Agile reduces the amount of up-front planning needed to get projects underway, so you can start creating valuable products and services for your users more quickly. However, organisations that are new to Agile often have concerns about how to make the output of their teams predictable. Velocity is a great metric for measuring the progress of your Agile teams. In this post, I’ll explain how to measure velocity and how it can be used to help plan releases. I’ll also point out its limitations as a predictive tool.

What is velocity?

Simply, velocity is the amount of work your team gets through in a set amount of time. As with the burndown charts that I talked about in my last post, velocity can be measured in person-hours, number of tasks, story points, or whatever other unit of measurement you use for estimating work.

For example, in KanBan, teams tackle a constant stream of incoming tasks which are all roughly the same size. Here, you might measure velocity by the number of tasks marked as done in a single day. By averaging these daily velocities over the course of a week, you could then estimate how much work the team would be able to get through in a longer period of time.

Here though, I’ll be focusing on how velocity can be helpful in Scrum. That’s the framework that tends to get used on digital projects which work towards a definite release schedule. The velocity of a Scrum team is the number of story points (or person-hours etc) completed in a sprint.

How to measure velocity

Let’s imagine a hypothetical team and give them a suitably Apprentice-style name.

Team Ignition planned to tackle 41 story points in their first sprint. They completed 28 story points, and rolled 13 story points over to the next sprint. So their velocity is 28.

Note that we’re not counting any partially-completed work towards the team’s velocity. Only tasks marked as ‘Done’ count, even if there’s only a tiny bit of work left to do in the task.

What does this tell us about the productivity of Ignition? Not much, so far. We know that the team fell short of their target for how much work to complete in the sprint. But we’re not really sure how far short they fell (we don’t know how close to completion the rolled over tasks are).

Over one sprint, velocity isn’t a very useful metric for making predictions. (But it does give the team a sense of how much work they can commit to in a single sprint.) Let’s track their progress for a few more sprints.

Ignition got through 28 story points in their first sprint, 36 in their second, 28 in their third, and 30 in their fourth. So their average velocity is 30.5

This average, over just four sprints, is already much more useful than the snapshot we had after just one sprint. It’s easy to imagine how, with a backlog of already-estimated user stories, we could use this velocity to make predictions. We could predict how quickly the team could get through all the work. And we could make educated guesses about what features we’d be able to deliver in upcoming releases.

How to use velocity

The most important thing to remember about using velocity to measure productivity, and make predictions, is to serve with a generous dollop of caution.

Velocity is a great at-a-glance measure of a team’s performance. But it doesn’t contain all the contextual information you need to make really good predictions. For that, Product Owners, ScrumMasters and Release Managers need to put their wise old heads together and get down into the detail.

Velocity works best with long-lasting, stable teams which have lots of experience of working (and estimating) together. If the personnel in your team changes frequently, or suffers from extended absences, then velocity will be much less meaningful. The same is true if your product backlog is missing user stories (which, over a long-enough time frame, it certainly will be).

Lack of certainty over the future of your product can feel alarming, but it’s also one of the benefits of Agile. It gives you the ability to respond quickly to changing customer needs, and incorporate feedback into your products and services with as short a lead-time as possible. It more than compensates for the inability to plan out your releases in great detail, many months in advance.

Don’t make velocity your goal

There are some schools of thought in Agile which insist on #NoEstimates, eschewing any kind of estimation of story sizes, or medium to long-term release planning, in favour of concentrating only on getting working software increments out of the door. We understand that this purist approach is a bit too far of a leap for most organisations at present. Especially those who are transitioning to Agile ways of working. But hopefully, just knowing that this approach exists (and can be very successful), is enough to help you stop clinging too tightly to velocity as a measure of value.

Remember: velocity is a tool for making predictions, not an end in itself.