How to measure and use the velocity of Agile teams

how to measure velocity in Agile

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's velocity after one sprint is 28

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's average velocity after 4 sprints is 30.5

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.


Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Bola says:

    Thank you for publishing this article. I like the simplicity and clarity of your writing style and the content of the article itself. So, basically at any point in time, the average velocity of the team is their VELOCITY.

  2. […] the above points (basics) are being done well, can a team start to seriously look to improve their velocity and scale […]

  3. […] Measuring team velocity evaluates how much work a team accomplishes during a set time period. Like development time, it looks for holes in the development process. It’s important to remember that team velocity should be measured within a set team at given intervals, rather than comparing one team to another. Comparing teams on one metric leaves out too many factors about their road to success. […]

  4. […] and potential risks – again, avoiding surprises. Design sprints also allow us to measure design velocity, so we can make sure the design and UX/human factors team is sufficiently staffed to keep ahead of […]

  5. […] work. Applying the team’s velocity to the remaining user stories in the product backlog can predict the completion date of the project. Of course, the more history there is to pull from, the better the prediction will […]

Sign up for the Manifesto newsletter and exclusive event invites