All You Need to Know about Velocity in Agile

Velocity in agile is an important metric that helps the team improve efficiency by determining how much it can achieve over time. After every iteration, the team adds up effort estimates associated with user stories that were completed. In project management, this helps in determining how long it will take to complete the project.

What is velocity in Agile?

Velocity in agile is a measure of how much work an agile team can deliver on average in a sprint.

It takes a view at measuring:

How much work an agile team has delivered in the past sprints
How long it took the team to get the work done

With this in mind, the agile team and its stakeholders can accurately estimate the agile team’s capacity, i.e. how much work they can achieve in a specific duration, i.e. in a sprint.

In essence, velocity in agile offers agile teams a way of calculating how fast they’re getting work done, and as a result, how many sprints will be required to get a project to a certain degree, and overall, create significant change.

Key factors to consider when measuring agile velocity for your projects

Like we’ve established, the need for agile velocity arises from wanting to know how fast an agile team can iterate and deliver features that incrementally develop the project. There are several factors that come into play when determining how fast an agile team can deliver.

1. Sprint workload

How much work are we delivering in this iteration? Specifically, how many backlog items, user stories are we moving from to-do to done within this sprint?

2. Sprint length

How long is this sprint going to last for? How long do we have to deliver our outlined workload? Is it feasible based on previous sprints?

3. Burndown chart

The burndown chart shows the action items the team has to execute, plotted against the amount of time remaining in a sprint.

How to calculate velocity

Velocity in agile is a fairly simple concept to calculate. All you have to do is measure the total amount of backlog items that were delivered per sprint.

As the team runs through more iterations, you can determine an average amount of backlog items, or ideally, a slim range of backlog items or features the agile team can deliver per sprint.

Velocity makes it easy for agile teams to estimate how much work they can achieve per sprint and how long it’ll take to get a project to a certain level of growth.

Agile velocity is measured in either days, ideal days, or the number of hours it takes the team to deliver a number of backlog items, story points, etc.

FAQ about measuring velocity

Here are some frequently asked questions about agile velocity:

1. How do I calculate the velocity for my agile team?

Divide the number of backlog items or user story points that’s been delivered during the course of several sprints by the total number of days in those sprints.

2. How is the agile team’s initial velocity calculated when there’s no previous record?

It is not, it is estimated or more specifically, projected.

Initially, it might be difficult for an agile team to estimate the amount of work that can be delivered in their first iteration. A good experimental estimate is to allocate just 30 percent of the work to that initial sprint.

For example, if a sprint is projected to last 2 weeks, with 6 teammates working on the target items identified, the total capacity available equals 84 days (expert-days = 7 days * 2 weeks * 6 experts).

The team should plan out 28 expert-days of work for this two-week sprint, with lots of buffer time for the team’s auxiliary needs like answering calls, writing emails, cross-team needs, unforeseen circumstances, etc.

With the results from this initial sprint, the agile team can watch whether they exceeded or performed below expectations and adjust gradually before there’s enough data to determine how fast they’re moving.

3. Should agile velocity be widespread across the organization or localized to individual teams?

Ideally, velocity in agile should be localized only within a team.

Why?

Because across other teams, several variables come into play. Other teams may perform different work, have different staff count, or have different strategic targets.

But in a situation where much of the teams within an organization do cross-functional work, agile velocity can be calculated for individual teams as well as adjusted organizationally as the need may arise. This mostly because teammates and resources can be moved from lower-velocity teams to where higher velocity is needed.

4. What happens if the velocity fluctuates?

If agile velocity fluctuates within a safe bracket, the agile team might have to analyze to pinpoint what’s changing and how to address it. In the bigger picture, widely varying agile velocity may affect bigger picture project targets and require changing deadlines, adjusting plans etc.

5. What’s required to get the velocity to stabilize?

When agile velocity fluctuates, the agile team should find out what changing data point or situation led to it and address it—as long as no other significant part of the project is affected adversely.

Otherwise, under normal circumstances, agile velocity stabilizes within 3 – 6 iterations.

6. How do I estimate agile velocity for future sprints?

The aim of measuring agile velocity now is to make it easy to accurately estimate future agile velocity. So, to estimate future iterations, apply the range you’ve arrived at over previous sprints —assuming no significant factor has affected the team’s productivity.

7. Can velocity be estimated if the agile team’s size changes? How?

All things being equal, changing an agile team’s size will affect the volume of work it can deliver.

A good formula is to alter a coming sprint’s expected velocity by the number of resources that’s been removed from the agile team. If a staff that contributes 10 expert-hours (team size * number of hours in the sprint) of input out of 40 expert-hours per sprint, removing that staff from the team would require reducing the team’s velocity by at least 25% to match the drop in capacity.

How does velocity help agile teams?

More than just a shiny metric that shows how long on the average it takes an agile team to run through sprints, velocity in agile is indispensable to growth-focused agile teams looking to scale iterations faster.

For example, by looking at an agile team’s velocity, it can be determined that adding extra team members and resources can increase team productivity, making it easier to run through sprints, i.e. deliver target items faster.

On the other hand, an agile team that’s running faster than is required for the entire organization can have its resources safely redirected to other teams operating at a lower velocity.

It all works hand in hand. And because of that, velocity isn’t a metric you can afford to overlook within your agile strategy.