How to Measure the Velocity of Agile Teams?

Velocity is a rather simple but powerful method for accurately measuring the rate at which Scrum teams deliver business value. What should project managers and their teams know about this method? And how to measure Velocity easily?

What is Velocity?

If trying to give a short and simple definition, Velocity is the amount of work your team gets through in a specific amount of time.

When iteration ends, the team adds up effort estimates associated with user stories that were completed during the iteration. This is velocity.

Velocity can be measured in person-hours, story points, a number of tasks or other units of measurement that can be used for estimating work.

In Kanban, teams work with a constant stream of incoming tasks. They can measure velocity by the number of tasks marked as done in a single day. If average these daily velocities over the course of a week, product managers can then estimate how much work the team would be able to get through in a longer time.

Velocity can be also helpful in Scrum. The framework tends to get used on digital projects that work towards a definite schedule. The velocity in Scrum is the number of story points or person-hours completed in a Sprint.

Knowing velocity, team members can recognize or revise an estimate of how long the project will take to complete. This prediction is usually accurate.

What are the origins?

Such early texts as “Planning Extreme Programming” were rather favorable to measuring Individual velocity. However, the practice fell into disrepute over the next few years. Story points were the most widespread unit of estimation and displaced Ideal weeks.

• In 2000 the term started to be the late addition to Extreme Programming, replacing a previous notion of “load factor” deemed too complex.
• In 2002 the Scrum community picked up the practice of measuring velocity.

Expected benefits of velocity

Agile-oriented teams usually acknowledge only two levels of completion: 0% done and 100% done. However, there can be a story at the end of the iteration that is only 70-80% complete. Therefore, it is not counted toward velocity.

Velocity is also used for limiting the amount of work taken on in further iterations. It serves in a few different ways as a regulatory mechanism.

How to calculate Velocity?

Calculating velocity in Agile is quite simple. All you need is to sum up the total estimates (days, story points, ideal days or hours) of user stories, requirements or backlog items that were delivered within a previous iteration/Sprint.

It’s a good idea to plan initial velocity at one-half your team’s total available time. Just keep in mind that you need to account for overhead.

Velocity сharts

Measuring the velocity (along with release and iteration burndown charts) has proven to provide effective visibility into project progress and status.

A velocity chart demonstrates the sum of estimates of the work delivered across all iterations. It’s expected that velocity will stabilize through the project life unless the team make-up or the length of the iteration changes.

Velocity can be used for future planning. This is a typical velocity chart visualization:

For teams that are new to Agile software development, it’s better to simply dive in and select an initial velocity using available information. Very quickly, they will see how velocity can be measured and adjusted.

Actually, velocity tremendously simplifies and accelerates the entire project planning and estimation, status tracking and reporting process.

Tracking Velocity with online services

Available Velocity charts that the most popular project management platforms propose, help to visualize the amount of value delivered in each Sprint and enable you to predict the amount of work the team can be done in future Sprints.

Here’s how the Velocity Report looks in Hygger:

Maximum velocity = maximum productivity?

This statement is not true.  

Trying their best to maximize velocity, the team can achieve the opposite. If asked to maximize velocity, teams can skimp on the unit or acceptance testing, skip bugs, reduce collaboration, minimize refactoring, etc.

The right goal is an optimal velocity over time but not maximized velocity.

Using Hygger Velocity report or other appropriate PM tools, you can start trending your team’s Velocity and have visibility across all of your teams in one place.

Reusing this Velocity data, you may create new recipes to measure the health of your product backlog and even remaining days in an open Sprint based on average Velocity.