The Agile methodology is based on one core idea — deliver and reiterate.
In other words, you’re not trying to build an entire system in one go.
Instead, you deliver a product that satisfies customers in a short period of time and you continue to develop incrementally.
Agile methodologies allow organizations to respond quickly to market changes and deliver more value to their customers.
With these competitive advantages, it’s not surprising that 95% of organizations now practice Agile development.
Following the Agile planning process is essential for this type of rapid development. But equally important is measuring team performance and the work that actually gets done.
After all, what good is a plan if you don’t follow it?
This is where Agile velocity comes in.
In this article, we’ll give you an in-depth look at what Agile velocity is and how it’s calculated. We’ll also give you a template you can use to track and monitor these values.
Get started with staging-mondaycomblog.kinsta.cloud
What is Agile velocity?
Agile velocity is a measure of how much work your team gets done within a specific timeframe. It’s used to help Scrum teams create more accurate timelines.
Agile velocity is a way for Agile teams to measure the progress they’re making on a project.
Velocity is determined by the number of total story points that are delivered in a sprint or iteration.
This won’t make a lot of sense unless you already know what story points are. So let’s review.
What are story points?
Story points are a measure Agile teams use to estimate the overall effort it takes to complete an item or user story in the product backlog (list of features and requirements for the project).
Story points don’t equate to hard numbers. Instead, they’re usually based on general ideas or relative difficulty.
At staging-mondaycomblog.kinsta.cloud we like to equate 1 story point to roughly 1 day of work.
But if you’re working on an unfamiliar project or have a new team, it might be hard to even guess what you can get done in a day.
That’s why some teams prefer to use the concept of relative difficulty.
Here’s an example of how story points are determined:
In this scenario, a task with one story point won’t require much effort, but a task with 4 story points might require more coffee (or Red Bull) than usual to finish.
The role of the product owner in an Agile team is to help the team define and prioritize stories as well as estimate story points.
When every feature, task, requirement, and bug is assigned a story point, the team can use sprint velocity to estimate how much work they can realistically complete during a sprint.
Without story points and an understanding of Agile velocity, figuring out how much work to assign a sprint becomes a guessing game.
That’s why Agile velocity is such a useful metric for Scrum teams.
Now let’s look at how Agile velocity is calculated.
How is Agile velocity calculated?
Agile velocity is calculated by taking the average number of story points completed over the last several sprints. Points from incomplete stories are never counted towards the actual velocity.
Here’s a sprint planning board from staging-mondaycomblog.kinsta.cloud that displays work items and their story points:
The number of story points is 9 in the first sprint and 8 in the second sprint. Let’s say the story points for the next 3 sprints are 10, 8, and 7.
The average velocity is 8.4 when we add up the Story Points (42) and divide by 5 sprints.
This means the product owner and Scrum team can expect to complete roughly 8 story points in the next sprint.
The velocity numbers by themselves don’t reveal the whole story though.
Insights start to become more apparent as you monitor the Agile velocity’s path over time.
The product owner can look at the actual velocity numbers on a velocity chart to measure team performance over time. If a team’s velocity shows a steady increase, it shows they’re becoming more efficient and could take on more complex work.Velocity numbers can also indicate bottlenecks. For example, if a team’s velocity for a sprint falls well below the average, there could be an underlying issue.
Here’s an example of a velocity chart that’s trending downwards:
The product owner and team can view the velocity report and see where numbers are dropping.
If they discover a downward trend, it gives them an opportunity to investigate what’s going on and see if they can reverse the pattern.
Another way to track velocity is with a burndown chart — a graph that illustrates how much work is remaining in a project.
Here’s an example of what a burndown chart looks like:
The blue line on the burndown chart shows the ideal tasks or story points remaining (all the work that needs to get done). The red line shows the actual number of tasks or story points remaining.
Burndown charts show how your team is performing during each sprint. If the red line (actual) is above the blue line (ideal) then your team’s velocity is less than you expected and you’re falling behind.
Agile velocity is a useful metric for estimating timelines and measuring progress.
But it’s far from perfect.
What are the drawbacks of measuring Agile velocity?
New teams generally experience a steady increase in velocity.
They become more efficient at their work and they start to build trust — one of the most important factors of a team’s effectiveness according to a study from Google.
But it’s important to note that velocity numbers are unique to each team.
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.
How one team determines Story Points may be different from the other.
For this reason, you shouldn’t compare velocity numbers between multiple teams because their estimations are likely unique to their work.
Another drawback of Agile velocity is the push to get Scrum teams to continue increasing their velocity numbers.
This can cause teams to rush through their work, which can impact the overall quality of the final product.
If velocity numbers are lower than usual, it doesn’t always mean there’s a bottleneck.
Numbers can fluctuate when new team members join, when processes get updated, or when the complexity of a task gets underestimated.
Keep a close eye on velocity numbers, but be mindful of these drawbacks as you do because they don’t always tell the full picture.
Tracking Agile velocity with Agile management software
Agile velocity is a useful way to measure your team’s performance over time. But you need to be able to easily assign story points and create Scrum velocity reports.
Having all of this information accessible from one location also facilitates collaboration and enables your team to stay on track when you run daily Scrum meetings.
Here’s a look at how Anna Haney from Noviqu uses staging-mondaycomblog.kinsta.cloud to plan their Agile sprints and track each sprint backlog item:
Read this customer story to learn more about how Novique uses this sprint board in their organization.
Then go ahead and customize the free template to work for tracking your team’s velocity.
Agile velocity plays a key role in Agile software development.
It can provide insight into how your team is progressing with their work, allow you to make better forecasts, and ensure your team doesn’t try to tackle too much at once.
As promised, here’s a Scrum sprint planning template you can use to plan your sprints and track your team’s velocity numbers. The template is fully customizable, so you can add new action items, adjust the columns, and much more.
Get started