What Is Velocity In Agile and How to Measure It?

Velocity in Agile refers to the estimated effort associated with work items that a team can complete in a given timeframe. It's an important metric in Agile, and teams use it to measure the amount of work they can deliver in a single iteration. 

Agile velocity is widely known from the Scrum process, where developers break down their work into user stories. Usually, to determine whether one user story will fit a single sprint/iteration, they measure its necessary effort in story points. Therefore, the number of story points a team can deliver in an iteration forms their velocity for that development cycle.

What Does Velocity Mean?

The official definition of velocity from physics is "the rate at which an object changes its position". Many people confuse it with speed; however, there is a slight difference between them. Unlike velocity, speed has no direction, and it simply describes how fast an object moves regardless if it's going forward, backward, or sideways.

That's why some Agile teams focus on measuring their velocity. They aim to understand not just the speed they are working with but also how fast they can convert a work item into value. Alternatively said, in Agile, velocity measures a team's ability to deliver outcomes (an actual value that customers pay for) rather than outputs (completing as much amount of work as possible).

What Does Agile Mean?

Agile represents a mindset and a unique approach to managing projects that continuously gathers customer feedback and focuses on adapting to changes. In Agile project management, everything that teams do is seen from the customer's perspective. 

An example is the Scrum framework, where teams break down big projects into so-called user stories. They are designed to capture the customer's intent for the given product functionality and the business need behind it so that developers can deliver the best possible value. To measure the frequency and predictability of value delivery, they use Agile velocity. 

Keep reading below to find out how that happens.

How Is Velocity in Agile Measured?

Project velocity in Agile is measured by estimating the effort that a given set of work items will take to be completed. The most popular way to do this estimation is through story points which are widely used in Scrum. 

The process involves estimating the product backlog items (user stories) by allocating story points to each one of them. Those points represent the relative size of a user story or how much effort the developers estimate will take them to complete it from start to finish. Most frequently, teams use the Fibonacci sequence (1,2,3,5,8...) for their story points which is a great way to distinguish between a small work item (1, 2, or 3) and a larger one (5 or 8). 

Unlike traditional project management, Agile proposes high team involvement when planning projects. That's why teams engage in different estimation exercises. For example, in Scrum, developers use a "Planning Poker" technique to estimate in story points how much effort the product backlog items will take. This is an effective exercise because it happens at every iteration. It welcomes the opinion of everybody on the team and builds upon data from previous development cycles. 

Once the estimation is done, developers get on with the actual work. Then, at the end of a given iteration, they sum up their story points based on the work items they've been able to complete. The final result is the team's velocity for that iteration.

What Is the Agile Velocity Formula?

The Agile velocity formula is the formula for calculating what work teams can accomplish over time. The calculation of Agile velocity is affected by the total story points you've been able to deliver so far on a project and the number of iterations. The common mistakes when calculating agile velocity include comparing velocity between teams, calculating partially done work, incorrectly interpreting metrics, etc. 

The formula for Agile velocity is below.

Agile velocity formula

To calculate the average velocity, you should add up the total story points in the project and divide their sum by the number of iterations in which they were completed. The final result will be your team's average velocity. 

You can then use this metric to plan how many story points (respectively, work items) your team can complete in one development cycle. Furthermore, based on this information, you can also get an idea of how many more iterations it will take for the entire project to be finalized.

How to Calculate Initial Team Velocity?

To calculate initial velocity, it's recommended that you start by agreeing with the developers on what each story point (SP) means in terms of working hours. For example, 1 SP equals 4 hours, 2 SPs should respectively equal 8 hours, 3 SPs = 12 hours, 5 SPs = 20 hours of effort, etc. 

You should then look at your team's capacity and roughly determine how much time they can allocate toward the project. It's also essential to add a buffer covering unplanned events (ex. 20% of the team's capacity). 

Based on the working hours in a 2-week iteration and the projected team's capacity, you can approximately calculate how much time developers will have (you should consider the number of developers on your team). Once that's done, it's a simple exercise of converting the available hours into relative story points. The final result can serve as your team's initial velocity. 

Remember that this is done only to get you off the ground. You should inspect how many story points you can complete over 3-4 iterations before calculating your team's average Agile velocity.

How Does Agile Velocity Measure Efficiency?

As story points are units of measure for effort, this means that velocity in Agile can be used to determine how efficiently teams process work items throughout project development. 

In other words, when developers get used to working together over time, they might increase their average Agile velocity and complete more story points per iteration. If that's the case, this will translate into higher team efficiency because you would deliver more work in the same amount of time (2-4 week iterations/sprints) and capacity levels.

What Is a Velocity Chart in Agile?

The velocity chart in Agile is a graphic that indicates how many story points have been completed over several iterations. Alternatively, it tracks the amount of work (known as user stories in Agile) that a team has been able to deliver in a given period. 

The X-axis on the chart visualizes the total number of story points that a team has estimated to complete in a single iteration or over the entire project. On the other hand, the Y-axis represents the timeline where teams track how much work they've been able to deliver over several days (in a single development cycle) or multiple iterations until the end of the project. Depending on the chart, there is a downwards or upwards-pointing line crossing the graph that shows what's the current progress of the team and indicates how much more work they have remaining. 

One example of a velocity chart in Agile is the burndown graph in Scrum. It's a representation of the story points that developers have been able to "burn" (complete) over a given period (one or several iterations). The diagonal line on the chart always goes downwards, indicating the progressive completion of work and the rate at which developers accomplish that. To reflect that no job is done on a given day, the line will become straight and move to the right side. This will also happen when a new scope is added to the project. That's why it's best to use burndown charts to track your daily progress on single development cycles. 

When it comes to tracking the entire project's progress over multiple iterations, a better use would be the burn-up graph. As the name suggests, the line here is going upwards, indicating how much work remains to be completed. Usually, teams utilize the chart to determine how they're tracking against their plan. The burn-up chart is handy because it clearly portrays when a new scope is added to the project. In turn, this enables teams to plan based on their previous data how many more iterations are needed to reflect that change and finalize the project.

What Are the Examples of Velocity in Agile?

Let's give an example of measuring velocity in Agile. 

Imagine that based on your team's capacity, you've decided to complete 4 user stories in a 2-week iteration/sprint. After an estimation exercise, you've sized the user stories in story points: Story 1 - 3 points; Story 2 - 5 points; Story 3 - 5 points; Story 4 - 8 points. Combined, that makes 21 points for the iteration. If you're able to complete all of them in 2 weeks, then your Agile velocity for that development cycle will be 21 points. 

Now imagine that you've been through 4 iterations, practical and your velocity for them is the following: Iteration 1: 21 points, Iteration 2: 13 points, Iteration 3: 28 points, Iteration 4: 15 points. 

The average Agile velocity that we can derive from here is below.

Agile velocity example

Going forward in the project, you can use that Agile velocity to plan how much work you can commit to. For example, suppose that you have estimated that your backlog consists of 286 story points in total. After you subtract the completed ones (77), this means you have 209 points remaining. You can then divide 209 by your average velocity (19), which means your project could be completed after 11 more iterations.

Calculating remaining iterations on a project

How to Improve Team Velocity in Agile?

There are a few techniques that you can use to improve team velocity in Agile. One of the most prominent ones is to analyze where work gets stuck, uncover dependencies and blockers so you can find ways to reduce their impact. 

Other useful techniques include:

• Focus on visualizing the "Definition of Done" through process policies and acceptance criteria to make it clear for everybody on the team. This will help you prevent bugs and reworks. 
• Reduce context switching to keep the developer's focus on one thing at a time. This can be done by imposing Work In Progress limits, but also the Scrum Master should aim to shield the team from external distractions. 
• Break down the user stories into smaller pieces (if possible) to improve their flow. 
• Increase the Product Owner's involvement in the work process to reduce misunderstandings and make the user story's details clearer.