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:
- Velocity in Scrum – Introduction
- Actual and planned velocity
- Difficulties and risks associated with Velocity in Scrum
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.
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.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing