Agile velocity: how this important metric can help teams track success and boost performance

The core idea of the Agile methodology can be summed up into a few defining words: speed, quality, continuous improvement, and efficiency. This popular style of project management allows organizations to respond quickly to market changes and deliver more value to their customers. But how can teams effectively measure performance and the work that actually gets done under this model? How can they gauge the speed and progress of specific processes to ensure they’re constantly improving and on track to reach their goals? 

For this, Agile teams, specifically those following the scrum framework, rely quite heavily on Agile velocity — a popular metric that measures the speed teams operate at, often for future planning purposes. 

In this blog post, we’ll carefully examine this metric and its importance. We’ll also cover the limitations of relying too heavily on this metric, and explore how to leverage it most effectively with other data through a flexible project management software.

What is Agile velocity?

​​Agile velocity is the measurement of how much work a team gets done within a specific timeframe. These time frames, known as sprints, are fixed iterations generally lasting 2-4 weeks.

This Agile metric, popular amongst Scrum teams, is primarily used as a reference for more efficient and accurate sprint planning.

You can better predict how much work your team can handle in future sprints by tracking how much work they’ve completed in previous sprints.

And, while this metric seems relatively simple at face value — essentially just tracking how much work your team gets done in a fixed amount of time — because of Agile’s peculiarities in defining progress and effort, measuring this metric isn’t all that simple. 

For Agile teams, determining how much work gets done isn’t just based on the time a task takes, but also considers the the perceived effort of that task. In order to define effort in a consistent manner, Agile teams look at story points — a relative unit that measures task effort by considering different factors such as complexity, size, and risk. So, Velocity is determined by the number of total story points that are delivered in a sprint or iteration.

Why measure velocity in Agile? 

Velocity in Agile is a fundamental sprint-planning metric. It’s particularly beneficial for Scrum teams because:

• It’s a straightforward measurement of progress on a project, allowing teams to understand exactly how much is getting done each sprint. 
• It leads to more accurate sprint planning timelines because it gives teams a realistic awareness of how much work they’re capable of getting done in a sprint, so they can use this when forecasting future sprints
• It’s a way to understand team capacity because teams can see if the workload is too much or too little based on trends in this metric 
• It encourages organization-wide transparency because investors and other stakeholders gain numerical insights into how a team is progressing
• It embraces the idea of continuous improvement, which is the basis of Agile methodology. The practice of consistently monitoring velocity trends allows teams to spot bottlenecks and areas for improvement, and ultimately improve team productivity.

How to calculate velocity in Agile

After your team has determined how to measure a story point, the calculation of Agile velocity is quite simple. What you have to do is:

1. Assign story points to each task (also known as a user story). This will be done before the sprint begins. Experienced scrum teams will use previous measurements of Agile velocity to estimate how many total story points a team has the capacity to complete in one sprint.

• Example: Let’s say in a specific sprint (Sprint A) there are 5 different tasks, each assigned a different number of story points based on their difficulty. The first task, say creating app store infrastructure, is assigned 5 story points. The Scrum master determines the story points to allocate to the rest of the tasks as well. It may look something like this:
  • Task 1: 5 story points
  • Task 2: 3 story points
  • Task 3: 9 story points
  • Task 4: 6 story points 
  • Task 5: 4 story points

2. Add up the amount of completed story points at the end of the sprint. The total number of story points completed in a sprint is the velocity. Points from incomplete stories are never counted towards the actual velocity, even if they’re mostly done

• Example: Let’s say Task 1, 3, 4, and 5 were completed. After adding up the total amount of story points for these completed asks, you’d find the velocity of Sprint A to be 24. Because task 2 wasn’t completed, no story points from it can be counted. 

3. Repeat this process over multiple sprints to determine the average velocity. Simply add up the number of completed story points and divide it by the number of sprints. This is a more reliable measurement of a team’s capabilities because each sprint may differ based on situational factors. 

• Example:  Let’s say that in Sprint B 18 story points were completed, in Sprint C 26 story points were completed, and in Sprint D 20 story points were completed. By adding up all the sprint’s individual velocity (24+ 18+ 26 +20= 88)  and dividing it by the number of sprints ( 88 / 4 =22). The average velocity would equate to 22. 

What to do once you’ve measured Agile Velocity?

Now, Merely calculating a sprint’s velocity won’t provide your team with much value. Velocity numbers on their own don’t reveal a whole story. It’s only by monitoring Agile velocity’s path over time to draw quantitive insights, that this metric’s usefulness shines through. 

Here’s where velocity charts come in, which provide a visual representation of velocity over time.

(Image Source)

They make it easier to track and understand trends in this scrum metric to formulate actionable insights. You can use these charts to:

• Understand workload capacity. If a team’s velocity shows a steady increase, it can indicate they’re becoming more efficient and can handle more complex work. If a team’s velocity shows a decrease, it can indicate a lack of efficiency due to burnout — that the workload is too much to handle.
• Proactively spot bottlenecks. If a team’s velocity for a sprint falls well below the average, there could be an underlying issue with the organization of that specific sprint. Or if there are specific areas in a velocity chart with fluctuations, either increasing or decreasing, this often indicates a problem. 
• Identify areas for improvement. If a product owner discovers a downward trend in a velocity chart, like the example below, they can closely examine the chart to understand exactly where numbers are dropping. This gives them an opportunity to investigate what’s going on and see if they can reverse the pattern by making real-time adjustments. 

A strong project management software like monday dev will track your sprints and automatically use this information to create visual velocity charts for you to examine.

What are the limitations of using the Agile velocity metric?

While Agile velocity is a useful metric for estimating timelines and measuring progress. It’s not the end-all-be-all metric and can offer some limitations if not used properly, or relied on too heavily. 

These limitations include that:

It doesn’t measure work quality

Velocity only measures the amount of work that was completed, but completely ignores the quality of the work. A team’s velocity may be high and consistently increasing, but the team’s work may also be full of bugs and dissatisfied customers. 

It causes teams to focus too much on speed, often at the expense of quality 

Hyperfocusing on this metric as the key measurement of team success can create an environment where people sacrifice quality to improve quantity. This can cause an overall negative impact on a team and their progress and even burnout for team members to complete more work at any cost.  

You can’t compare velocity numbers between teams

Velocity is measured through the relative unit of story points — and because the way one team determines story points may be different from the other, velocity numbers are a highly-specific metric for each individual team, and can’t be used for comparative purposes.  For example, if one team has a velocity of 15 while another team has a velocity of 10, it doesn’t necessarily mean that the first team is more productive — it may just mean that they have a different system of measuring story points.  

Overall it’s best not to look at this metric as a surefire indication of success, but rather as a tool to understand patterns in team performance. Using an Agile project management software that captures and tracks all your data ensures you receive a full picture of an Agile team’s progress without focusing too much on a singular metric.

What is Agile capacity

Agile capacity is another important metric, that often works hand in hand with Agile velocity. The concept of capacity is well-known throughout any approach to project or work management as it plainly refers to the maximum availability of a person or entire team to complete work in a specific time frame. 

While Agile velocity retroactively looks at the amount of work a team has completed, Agile capacity refers to the available time or effort a team has during a sprint.

It considers external factors like team member vacations or other pre-existing commitments.

The Agile capacity is calculated before a sprint begins by allocating available resources to provide an accurate image of the amount of work that can be completed in a specific sprint. It’s used for short-term planning based on situational factors. 

How to measure Agile capacity?

Agile capacity is generally measured in hours. Say one sprint lasts 2 weeks with 5 working days (8 hours each). And let’s say 5 developers are working on the sprint. If you multiply the 8 hours a day, for 10 working days total for each of the 5 developers, you’d find the team capacity for that sprint to be 200 hours.

But then, you’d need to consider if anyone is taking time off or spending some of their hours on other projects. So if one developer is taking a week off (adding up to 40 hours), and another is planning to spend 2 hours a day on other tasks (adding up to 20 hours), the total capacity for that sprint would be 320 hours. 

Combining Agile velocity and capacity to estimate project delivery

For the most accurate estimations of a project’s delivery, and your team’s ability to complete tasks and projects within a timeline, it’s best to look at both Agile capacity and velocity. By looking at your team’s average velocity, you can understand how much your team can normally complete in a sprint based on historical data. But before planning a sprint based only on velocity, considering capacity is vital, so teams can appropriately collaborate and account for situational factors that might affect a team’s ability to complete their work. 

And while both Agile velocity and Agile capacity are important metrics, they’re not the only ones to consider. To gain a full picture of your team’s progress and performance it’s necessary to consider as many different metrics as possible. Other Agile metrics for scrum teams to consider include: 

• Sprint Burndown – visually represents a sprint’s progress showing how much work has been completed, and what is still left to be completed. 
• Net Promoter Score-  measures customer satisfaction on a scale of 1-10, based on how customer’s direct ratings. 
• Defect Density – measures the number of defects(or bugs) per unit of work, like story points, or a line of code. 

monday dev: the customizable software to best leverage Agile velocity and other metrics for success

An Agile team’s success comes from more than just tracking Agile metrics like velocity and capacity —  an Agile team’s ability to truly flourish hinges on their ability to visualize, understand, and gain actionable insights from these metrics. Enter monday dev, the intuitive product development software that provides a holistic view of your project progress, so you can manage all aspects of your Agile processes in one flexible place. 

Here’s how monday dev can help transform your team’s Agile workflows and ease all aspects of the product development process:

Consolidate all parts of your sprint management process in one place 

From sprint planning and daily standups to retro and sprint review, manage the lifecycle of your sprints directly in monday dev. Automatically keep track of story points, Agile velocity averages, and other progress measures in one cohesive place to gain a more holistic estimate of how much time & resources each user story will consume. 

Custom dashboards to visualize real-time metrics and Agile insights 

Our custom dashboards automatically use up-to-date information to generate reports from up to 50 boards. Bring your metrics to life with Gantt charts, Kanban views, Timelines, and more to spot any patterns, roadblocks, and trends in a format that makes sense for you. Our dashboards ensure your metrics are easily digestible and readily available to share with stakeholders.

Automatically feed story points into interactive burndown charts 

Visualize your sprint’s progress with burndown charts that bring your story points to life. These charts detect potential problems or bottlenecks by comparing the actual remaining effort with the ideal progress so you can make more informed decisions. 

These are just some of the various ways monday dev’s powerful capabilities can optimize your metrics for the utmost success. Set your Agile planning up for success by using one unified solution that integrates seamlessly with essential tools like GitHub, GitLab, Hubspot, and Figma to keep your entire project in one place.

Simplify your processes and turn your data into actionable insights with the click of a button. Try it yourself today with a 14-day free trial.