Schedule a call

That’s why I was concerned when our team released their velocity during the first couple of projects after we’ve transitioned to agile. I know we were doing it wrong. Now, years later, we’re confident that our experience can help you better understand agile velocity. Let’s get into it.

Velocity is a measure of how much work a team can complete in an iteration

It’s the pace at which we estimate the agile team to complete work in future sprints. In agile, velocity is calculated by summing up the total number of story points completed in an iteration (or by summing up the total number of hours).

The estimation techniques in agile are a topic for another article, but I’m sure many of you will hang-up on the parentheses above. We won’t go in-depth about the viability of using hours (or days) in agile estimates. I hope we can agree that there are no accurate estimates. If something doesn’t work for you, there’s no point in creating an illusion of being agile. Do the rational and smart thing. If that thing is estimating in hours, all power to you.

Velocity is most often expressed as a range rather than as a single number. This makes it more helpful for forecasting, planning, and budgeting. It accounts for all factors that may affect the result of your next sprint. That way, you avoid false certainty about what the team can do within one iteration.

How to calculate the velocity of agile projects

Let’s take the following example of completed sprints:

  • Sprint 1 – 8 story points
  • Sprint 2 – 13 story points
  • Sprint 3 – 11 story points
  • Sprint 4 – 15 story points
  • Sprint 5 – 6 story points

There are a few methods to calculate the velocity of the upcoming sprints. If the number distribution seems odd, I can assure you it’s quite realistic. As mentioned, many things affect iterations and their velocity. The first sprint might start off “slow” compared to sprints 2-4 because the team is just getting warmed up. There might be technical considerations, perhaps even some gaps to fill.

Then the pace picks up… so what about the fifth iteration? It’s possible that there were only a few user stories with low priority left in the backlog. Why do we still need to know the velocity? The product owner can always come back with additional requests. That’s the beauty of a flexible agile engagement.

Iterations must be of the same length for velocity to be accurate and meaningful

I think it goes without saying that you can’t estimate a velocity when your interactions have different durations. A 2-week sprint with a velocity of 20 will rarely translate into 10 story points in a 1-week sprint or 40 in a monthly sprint.

Agile teams can rely on velocity only when all their sprints have consistent duration. If there are variable lengths between two iterations, it’s not possible to compare them.

Velocity is established after a few sprints

You don’t have a velocity after just one sprint.

There, I said it.

You might not even have it after three, but that’s where it starts getting closer. It shouldn’t stop you from keeping track of your velocity, but just manage the expectations – both internal and external.

A team’s velocity will naturally vary over time, but should remain fairly consistent as long as:

  • The team composition stays roughly similar
  • The process and tools used stay roughly similar

USEFUL WEBSITE & MARKETING TIPS DELIVERED ONCE A WEEK

Includes tools to maximise your website potential.

Sometimes, we can calculate velocity based on past projects to give everyone some clarity. But that’s not the norm. Software development is an infinite, iterative process. You’re only limited by your imagination, so no two projects are the same.

However, they can be similar enough. In our case, building websites falls into that category. Unless it’s a bespoke project (like a headless site on a brand-new architecture), we’ve done very similar tasks in the past. It’s a blessing in disguise. You’ll hate me for saying this again, but accurate estimates don’t exist. And if an accurate estimation would be a unicorn, then I don’t know what to call an estimate based on a different project…

In short, it’s even less accurate. But we still need it. We need it as an agency, and you need it as a client. Agile is a different approach, so not everyone is comfortable committing to an “infinite” project. After all, resources of every single company are finite.

Don’t use velocity to calculate the cost of fixing bugs

Software development is complex. We communicate to our clients from the get-go that bugs are to be expected. They’re not the standard, and we obviously don’t produce code with the intention to have bugs. There are no shortcuts that cause bugs – this would be against the principles of agile. Bugs are there and we need to acknowledge them. But they aren’t included in a user story estimation.

Since bugs are unknown and unexpected, it’s almost impossible to estimate them, and you shouldn’t include them in the calculations. You can set time aside for bug fixes, or even have a dedicated developer working on them, but that can’t affect your velocity. If you’d like to know your “bugs per sprint” or something similar (which would help spot patterns and improve QA), use an alternative metric.

Velocity is a metric for the agile team and shouldn’t be measured for individual team members

This is the most common mistake people make regarding velocity. Velocity is a metric for the whole agile team and you should not measure it for individual team members. Never make that mistake.

If you are tracking velocity at the individual level, you’re missing the point. First, because all agile teams are self-organising, there’s no reason to compare one person’s productivity with another’s.

Second, each story point represents only a rough estimate of effort and complexity. It makes no sense to measure individuals against their estimates. You can work towards making their complexity estimates more accurate, but it’s not a performance metric.

Nobody can know how much work each person will do in a future sprint. If we could forecast what everyone will do in each sprint, then we wouldn’t need scrum or agile in the first place!

Velocity is one of the best ways for you to understand the amount of work an agile team can deliver

Velocity is a perfect estimation tool because it considers all the other things that can get in the way, like interruptions and team meetings. It focuses solely on telling you how many user stories can you complete in a typical week based on their complexity.

Velocity is not concerned with whether a single task took an hour or two. In the grand scheme of things, it doesn’t matter. Above anything else, velocity is an internal metric used to improve the performance of a team. It’s helpful to communicate it to stakeholders for various reasons – like transparency, budgeting and prioritisation. But in the end, it’s not a measure of success. It’s not a target for the team either. Velocity is a product of an iteration. This is an important distinction that should dot the i’s and cross the t’s in this article.

Originally published Apr 22, 2022 6:28:56 PM, updated April 23 2022.

Don't forget to share this post!