What is Agile Velocity? A Guide to Estimation & Sprint Planning

What is Agile Velocity?

Velocity measures the work a team can complete during a single sprint. Teams calculate velocity by adding the story points of all stories they complete during the sprint. If a team completes stories totaling 30 story points during a sprint, its velocity is 30.

Why is your velocity important?

Knowing your team's velocity allows you to convert story points to time and answer questions such as:

1. Should we build feature A rather than B, delivering 80% of the value at only 20% of the cost?
2. What can we expect to deliver before the end of next quarter?
3. When can we expect to deliver a particular feature?

To answer these questions, we need to convert story points completed (i.e., velocity) to time so that we can forecast our progress. First let's cover how velocity is measured.

How is sprint velocity measured?

Building on top of the fruit metaphor from the last post, What are Story Points, let's assign numbers (from the Fibonacci scale) to each fruit so we can add up and measure the team velocity during a sprint:

• 🍓 Strawberry: 3 story points: Represents a small story with minimal effort.
• 🍏 Apple: 5 story points: Represents a medium-sized story with moderate effort.
• 🍉 Watermelon: 8 story points: Represents a large story that requires more effort

Based on this scale, if the team averages 30 story points/sprint, it can be expected they will complete:

• 3x 🍉 = 24
• 2x🍓 = 6
• = 30 story points

Or

• 2x 🍉 = 16
• 2x 🍏 = 10
• 1x 🍓 = 3
• = 29 story points

Or any combination that adds up to approximately 30 story points.

How does velocity map to time?

Because each sprint is time-boxed and contains the same number of days, teams use their current velocity to forecast how many story points are expected to be completed in one, two, three, or any number of sprints. Given an average velocity of 30 story points, a team would complete stories totaling 30, 60, and 90 story points, respectively.

Teams' velocity will average out during the team's last few sprints

Overall, the team's velocity will be approximately the same over the previous few sprints, given that each team member spends the same amount of time working in the sprint. The team's velocity can improve or decline depending on the environment established around the team. Before touching on this, let's cover how to handle holidays and team member vacations when measuring velocity.

How to handle holidays?

Let's say your team is running a week-long sprints, and the upcoming sprint includes one official holiday — how should this be addressed? Since the next sprint will consist of only 4 out of 5 working days, and the team's velocity is 30, we can expect the team's velocity to be 0.8 * 30 = 24 story points.

How do you handle the case when one team member is away during the sprint?

Let's say your team is planning the next sprint, and one team member will be on vacation. If the team's velocity is 30 and the team consists of six members, with only five participating, we can expect the team's velocity to be 0.83 * 30 = 25 story points.

Is your team's velocity getting better or not?

It's important to note that a team's velocity is not constant. It improves or declines depending on factors you, your coworkers, and your clients have control over. We need a separate post to cover this topic well, but here are a few highlights:

Factors negatively impacting the team's velocity:

1. The team is cutting corners in an attempt to deliver on an impossible deadline
2. The level of codebase technical debt is high
3. Coverage of automated tests is low

Factors positively impacting the team's velocity:

1. The team is working at a sustainable pace and given time to remove obstacles holding them back
2. Technical debt is being continuously reduced
3. Automated testing is added each sprint; more and more problems are found and fixed early

Next step - Mapping Story Points to hours

Now that we know how a team's velocity is measured, we can answer questions like these:

1. When can we expect to deliver a specific feature?
2. What can we expect to deliver before the end of next quarter?
3. Can we get a specific feature delivered before the end of next quarter?

The following post in the series answers these questions: Story Points to hours - how does it work?