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.

Scrum Guide:

1. Glossary of basic terms, roles and notions
2. What is Scrum?
3. Scrum values
4. How to implement Scrum in your company?
5. Scrum Team - what is it and how does it work?
6. Who is a Product Owner?
7. The most common mistakes of Product Owner
8. Who is the Scrum Master?
9. Characteristics of a good Scrum Master
10. The most common mistakes of Scrum Master
11. What statistics and metrics should the Scrum Master track?
12. Cooperation between Product Owner and Scrum Master
13. Development Team in Scrum
14. The most common mistakes of Developers
15. Scrum artifacts
16. Scaling Scrum
17. Sprint Backlog
18. What is the Product Backlog?
19. What are User Stories?
20. Creating the best User Story with INVEST
21. The most common User Story mistakes
22. User Story Acceptance Criteria
23. Estimation and Story Points in Scrum
24. Planning Poker
25. Team Estimation Game
26. Defining Increment
27. Scrum events
28. What is Sprint in Scrum?
29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
30. What is a Burndown Chart?
31. How to create and interpret a burndown chart?
32. Advantages and disadvantages of the burndown chart
33. Kanban boards in Scrum and Scrumban
34. Velocity in Scrum - Speed of the Development Team
35. Daily Scrum
36. Sprint Planning
37. Sprint Review
38. What is a Sprint Retrospective?
39. Common mistakes during a Sprint Retrospective
40. Product Backlog nurturing