The adaptive approach emphasizes the frequent delivery of value. To predict the team’s delivery capacity in each iteration, Scrum practitioners use a metric called velocity. What is it? How does it support Agile teams? What tools to use to calculate velocity in a Scrum team? It’s time to find out.
What is team velocity in Agile?
Scrum Inc defines velocity as “a measure of the amount of work a Team can tackle during a single Sprint.” More specifically, velocity is the total number of story points from the fully completed user stories in a Sprint. It’s a valuable metric because it allows the team to monitor the pace of work and use it as a baseline to improve its effectiveness in future Sprints. In Scrum, improvement is incredibly important. That’s why it’s better to look at the progress rather than using terms like good or bad velocity.
If the Product Owner wants to include additional stories in the scope of a Sprint, the team can gauge whether it will be possible to deliver the entire Sprint with the addition. Alternatively, the Developers have a data-supported argument and they can say “Recently, our velocity has been X. Based on that, we may not be able to deliver the modified scope.” Then, the Scrum team can discuss the situation and decide to set some items aside for the next Sprint to make room for the new addition. Knowing the team’s velocity can help make an informed decision.
Benefits of measuring velocity in Scrum
The metric helps visualize the progress in team performance. It’s not a goal in and of itself. If the Developers are able to deliver more story points throughout Sprints, it means that the improvements discussed during the Retrospective are effective.
Additionally, the Sprint’s velocity can act as a point of reference to establish realistic limits for the team’s work in an iteration. If a Scrum team delivers much fewer complete user stories than it planned throughout multiple Sprints, it might signal the need to reevaluate the size of the scope assigned during Sprint Planning.
Some say that knowing the team’s velocity allows the Product Owners to roughly estimate the number of Sprints needed to deliver all the Product Backlog Items in a project. However, the team would need to estimate all the user stories in the Product Backlog to do that. Naturally, such estimates have to be taken with a grain of salt. After all, no agile project is set in stone. Adding new items to the backlog will impact the number of iterations needed to complete the initiative.
For velocity to be even remotely accurate, it’s best to apply it to a particular feature instead of a whole project. Additionally, both the product and its direction must be relatively stable.
Pitfalls of team velocity in Scrum
Velocity may differ between teams considerably. The main factors that influence this metric include the team size, the Sprint length, the availability of Developers, and the approach to estimating user stories. With the latter being relative, there is no universal point of reference. Thus, seeing a large discrepancy in velocity reports of multiple Scrum teams is not a cause for concern.
It’s also important to note that juxtaposing the velocities of multiple teams is not an effective measurement. Instead, it’s worth focusing on improving the velocity of each team separately. Otherwise, it will foster an environment of unhealthy cross-team competition and may result in story point inflation.
Similarly, calculating velocity of singular team members goes against the philosophy of the framework. In Scrum, the entire team is accountable for the delivery of the Sprint. Consequently, the contribution of all the members makes up the team’s productivity.
How to calculate the team’s velocity?
Simply put, calculating velocity requires a sample size, appropriate data from past Sprints, and a formula to follow. Bear in mind that a single Sprint may not be enough to provide accurate results. The common practice is to look at the last three iterations to determine the team’s velocity.
As for the data, only the story points from the completed user stories in a given Sprint will count toward velocity. The crux is to learn how many user stories the team was able to deliver in its entirety.
Let’s look at an example of three Sprints that will visualize the process in detail. Each iteration contains four user stories.
In the first Sprint, one user story was incomplete, but the other three will be a part of the calculation. All in all, the Developers managed to deliver 12 story points.
The next Sprint also features a single incomplete user story and three delivered ones. Thus, the total amount of story points completed in this Sprint is 9.
In the last iteration, the Developers delivered all the stories they committed to – 12 in total.
Knowing the number of completed user stories in three Sprints allows us to get the average Sprint velocity:
Of course, you don’t have to calculate story points or the team velocity manually. Most project management tools that support agile development contain tools that will do it for you.
Tools that support sprint velocity calculation
Work management software such as Jira and project portfolio management apps like BigPicture contain a variety of tools that help Agile teams keep track of their performance. Some provide information about a single iteration, while others gather data across multiple Sprints. The following tools will be of great use for keeping track of team velocity.
Burndown chart
The idea behind the Sprint burndown chart is to visualize the amount of work the team completes during each day of the iteration. The chart starts with the sum of all story points in the Y axis and as time goes on, the amount of story points should drop. At the end of the Sprint, there should be no story points left to deliver.
The burndown chart applies to a single Sprint, but it provides the Scrum Team with valuable information. Firstly, it serves as a visual representation of the progress of the Sprint. Secondly, the values on the chart can signal that the work does not proceed at the right pace. If the source of the delay is caught quickly, there may still be enough time to solve it and deliver the full scope.
Jira Software includes a burndown chart in its stack of reports. Below is an example of a burndown chart in an Agile project managed in Atlassian’s tool.
Agile board
Those who need to manage an Agile project more holistically should look into a project management tool like BigPicture. On the project level, it will serve as the command center of all the team activities related to the iterative development of the product.
The Board module captures Jira project data and visualizes it in a comprehensive manner. That way, the Product Owners can easily see the progress of the scope committed to each Sprint, along with key information for each user story.
Whether it’s a team or individual view, the task cards display fields such as the story point amount, assignee, epic link, or dependencies, to name a few. In fact, the categories of information are fully configurable, so the cards can be modified to present any built-in or custom fields of your choice.
On top of that, the Board displays the capacity of the team and compares it with the allocated story points of all the tasks. That offers a quick insight into the allocation of the team. The data is based on the capacity planning values for each iteration, which can change depending on various circumstances and can be quickly set manually for the entire team or each member separately.
The module also features a backlog panel. As a result, scheduling a story and assigning it to a team is both easy and fast thanks to drag-and-drop.
Velocity chart
As the name suggests, the chart tracks the velocity of the team. However, that metric in itself doesn’t tell the full story. But when you add the overall capacity and compare the two, it paints a more detailed picture of the performance of the Agile team in previous Sprints.
That’s exactly what BigPicture Enterprise’s velocity report does. It presents the team’s velocity in the context of the overall capacity. The chart gathers the data from capacity planning and completed user stories in the given iteration automatically.
Generating the velocity chart only takes a few clicks. Just pick the appropriate report type, add the name, and select one of the teams. After each completed Sprint, simply open the report and the chart will display the up-to-date story point values.
Monitoring the performance of Agile teams and improving their efficiency is incredibly important, in Scrum or any other framework. Sprint velocity is a key metric in measuring the pace of delivery of Product Backlog Items. Moreover, it is an indication of the work the Developers can deliver in future Sprints.
Agile tools like the velocity chart improve the management aspect by displaying accurate work management data automatically. Make sure to use them when you track team performance throughout iterations.
