As a business owner or team lead, have you ever wondered what is your team’s productivity level? Do you even measure them so to know how effective is your team? This productivity rate is called Velocity. Knowing your team’s velocity allows you to better estimate your project timeline and also make better business decisions regarding your team resoures.

In this article, we will briefly go through the following questions

• What is velocity?
• What is a velocity chart?
• When do you need it?
• What does it show?
• What are its pros and shortfalls?

Want to go far, go together.

#1. What is Velocity?

In agile software development, velocity refers to the amount of work done given a set period of time; often times we can this period of time sprints.

Velocity is used to measure rate at which development team delivers value to business.

There are a few key principles of velocity:

1. Estimated development time

Knowing your velocity, the amount of work you can clear within a set of time; say 2 weeks, you are able to estimated how long does it take to deliver on an entire project with its clear requirements.

2. Identify team progress and potential

Given actual velocity, product owners and manager can determine if the team is coming more efficient over the development cycles.

If team’s velocity consistently increases after every sprint, it implies a learned team that is learning quickly. It also implies that your team is ready to handle more complex tasks. Always start small and slow. Then find the velocity of your team and bring the team together towards the desired velocity that you wish to achieve.

#2. What is a velocity chart?

Velocity chart indicates two things

1. the overall status of a project
2. How much work your team can handle in future sprints

Given these details from a velocity chart, you can highlight your team’s velocity during sprint planning, sprint review, or sprint retrospective sessions.

Here’s an example of a good velocity chart:

It is good for a few reasons:

1. It measures story points

Story points measure the effort you’ll need to complete your project’s tasks. You can use the time taken to complete the simplest user story as the baseline and assign 1 point for that.

So for example, if the simplest user story requires you to take 2 hours to develop is assigned 1 story point. Then a feature that takes 4 hours will be assigned 2 story points.

2. It allows you to compare across sprints

A sprint is the measure of development cycle time taken to complete a section of the project.
A sprint can vary from 1 to 4 weeks long.

It shows you how accurate are our estimation of our development team as you measure the estimation vs completion.

This estimation confirmation allows the team leaders to estimate the number of user stories can the team handle in future sprints.

#3. How do you measure velocity calculations?

Project velocity is calculated by taking the average of the total completed story points over the last five sprints.

Taking the example above as an example:
The team’s velocity is: (82 + 85 + 100+ 80 + 90) / 5 = 87.4

So the team can be expected to completed at least 87.40 story points worth of work in the next sprint.

#4. How is this useful for me as a project manager?

Knowing your team’s velocity allows you to estimate the number of sprints required to complete it. Knowing the number of iterations allows you greater certainty on when your team is able to roll out the final product.

Here’s an example to illustrate the point above:

1. Look at the velocity report of a similar project to determine your Agile team’s average velocity
2. Determine the number of user stories your team will be working on in a particular project
3. Add up the story point for each user story to be completed in that project
4. Divide the total number of story points with your team’s velocity

Here’s this procedure in action:
Let’s say your Agile or Scrum team has to work on three user stories in a project: A, B, and C. 
A and B are worth 400 story points each, and C is worth 70 story points.

Your team has to work on (400 + 400 + 70) = 870 story points in one iteration.
Now judging by the previous velocity chart, your team’s average velocity is 87.40 story points.

By dividing the two Agile metrics, we get: (870 / 87.40) ≈ 10
We can estimate that it would take approximately 10 sprints for the team to clear the product backlog.

Assumptions: the team continues to work with the same velocity. No leaves, no new employee or employees leaving. These could be critical factors for your team’s velocity. So the lesson here is to buffer and give yourself some breathing space for uncertainty.

#5. What are the benefits of the velocity charts?

1. Helps you to better predict your team’s capacity

If your current sprint requires you to complete tasks A, B, and C worth 13, 12, and 5 points respectively. If your team’s current velocity is only 20 story points, it would be predicted that your team will struggle to complete the allocated tasks for the current sprint.

2. Allows you to be proactive against potential issues

If you find your team’s velocity dipping over the sprints, it could signal hiccups.

These issues can include:

• The tasks’ execution requirements are not properly considered in the tasks’ estimation.
• Poor team communication, where your scrum meetings are not as effective as you think they are.
• Low productivity: Your team might be facing challenges or obstacles trying to develop the user stories.
• Excessive product bugs: your product’s quality might be worse than it is thought to be.

Having these signals help to ensure these issues are addressed early before it snow-balls and affect the business as a whole.

#6. What are the velocity chart’s shortfalls?

1. It is not a precise measurement

It is all but just an estimation of your team’s velocity. It is only a tool to allow you to better and more accurately predict your delivery timeline. However, it is still hinged on many assumptions such as employee’s sick leave or non-technical blockers such as a new process introduced to the team, or changes in project scope.

2. You cannot objectively compare the velocities across companies.

As different companies may have different processes, tools, product quality, the time taken for a particular user story will defer across companies. So even if both companies use the same unit of velocity, for example story points/sprint. It does not consider the pertinent differences that are non technical.

TLDR;

If it is important, measure it. Team velocity is important for you to know the productivity rate. And thus can better estimate your ROI on your team’s cost. You want to track them, and then be able to use them as better indicators to address issues proactively. In technology, a good team of A players can be costly. Plan your cost properly.

Reference:

• Clickup’s description on Velocity charts

Here is a youtube video explaining what is a user story point and how can it be used. Hope you enjoy.