Scrum Guide | 34. Velocity in Scrum – Speed of the Development Team

Velocity in Scrum helps you to determine the rate at which the Scrum Team completes tasks. We can define it as the average number of Story Points completed in one Sprint. Velocity can also estimate the duration of a project based on work progress already completed. However, this only makes sense for a mature team that works at an even and steady pace. Take a look at what Velocity is and how to make it work best for you!

Velocity in Scrum – table of contents:

1. Velocity in Scrum – Introduction
2. Actual and planned velocity
3. Difficulties and risks associated with Velocity in Scrum
4. Summary

Velocity in Scrum – Introduction

Velocity is an optional but popular method to measure the pace of a Scrum Team. This is because an accurately estimated Velocity enables predicting, to a reasonable extent, the time needed to complete a project. However, it is a measure that can only be applied to a given Development Team, which will perform tasks that it has “valued” itself using a familiar unit, such as Story Points, for example.

The Velocity of the Development Team is most often presented in the form of a Velocity Chart. On the X-axis are marked consecutive Sprints. On the Y-axis, on the other hand, we will find the number of Story Points or other corresponding units that were completed in a given Sprint. With the Velocity Chart, the Scrum Team gains a clear view of changes in the pace of its work. If the line marked on the chart is rising, it means that the Team is optimizing its efficiency or reducing the value of Story Points. Both the Scrum Master and Product Owner should therefore carefully follow the line showing the Team’s Velocity.

Actual and planned velocity

The actual Velocity of the Development Team describes the pace of work in the completed Sprint and is calculated at the end of each Sprint. It takes the value of the sum of Story Points for all completed User Stories. The actual Velocity of the Development Team allows you to plan and estimate with some probability the pace of future tasks.

The planned Velocity, on the other hand, is estimated based on an average value of the actual Velocity. It requires the assumption of no change in the Development Team. It is an important internal tool for the Development Team, which, based on it, can assess whether cooperation in the Team is going well and whether the pace of work is being maintained.

Planned Velocity also enables the Product Owner to forecast the execution time of well-defined User Stories scheduled for execution in subsequent Sprints. This enables more efficient nurturing of the Product Backlog, which we wrote about in this article. However, the practice of applying planned Velocity to estimate project durations is not so simple.

Difficulties and risks associated with Velocity in Scrum

Velocity in Scrum is often given too much importance without considering the following factors:

• estimating larger wholes or the entire project – while the Development Team can accurately estimate the number of Story Points to be assigned to a specific task, it is very difficult or impossible to describe larger wholes for future implementation in these units
• changes in the project – any change in the project potentially means a change in the number of Story Points needed to achieve the Product Goal. It may also be that tasks already completed will need to be modified or even not used in the final version of the Product
• unforeseen events – predicting the pace of future projects based on those already completed, that is, translating actual Velocity into Planned Velocity, can result in accurate estimates. However, each project has its peculiarities and an accurate prediction based on history is usually impossible.

Summary

Using Velocity as a metric to evaluate the effectiveness of the Development Team can cause its reliability to degrade. It can also degrade the quality of the estimates, which we wrote about in more detail in this article. After all, to get the best possible results in the metrics, the Development Team may overestimate the labor intensity of tasks to increase Velocity. This is detrimental as the team itself then loses valuable information to make improvements and plan its tasks more accurately.

Velocity in Scrum comes in handy primarily as an internal measure used by the Development Team to evaluate the pace of its work. This is because it allows it to determine how many tasks it is capable of completing during a single Sprint.

Velocity in the hands of the Product Owner becomes a useful tool for estimating the deadline for larger tasks.

However, the biggest risks are associated with using Velocity as a metric for evaluating the Development Team. This is because it can lead to a lowering of its credibility and even a deliberate overestimation of its value to improve the external evaluation of the Scrum Team’s work.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.