As we are aware, Scrum is a framework of repetitive and incremental elements in project management. The Scrum technology has its projects divided into a number of sub-processes. Each of these sub-processes is referred to as Sprints. The sprints can be one week, two weeks, or three-week duration. But what is the velocity with respect to Agile Scrum technology and how to calculate velocity in Scrum? Let us try to understand the concept of velocity in Scrum.
What is Velocity in Agile systems?
Well, Velocity is a simple measure of the work completed by a Scrum team in a predefined period of time. There are several ways the metric of velocity can be measured. A few prominent examples of measuring the velocity can include person-hours, number of tasks, or story points.
Out in a specific concept of Scrum, velocity can be defined as the number of story points completed in a particular sprint. In fact, velocity can be a simple measure that can be used to measure the rate at which the Scrum development team has been able to complete a task and delivered the business value.
How to Calculate velocity in Scrum?
Calculating velocity in Scrum involves only those sprints that have been completed. Any partial completion is not counted for the calculation of velocity.
In essence, calculating velocity in Agile in general and Scrum, in particular, is rather easy and straightforward. You just need to sum up all the estimates and take an average of those values. It can be one of the excellent options for future planning.
Let us make it clear with an example:
Let us assume the Team Apprentice (or whatever name you would prefer to give it), and has planned a work spread across three sprints. As we are aware, each sprint has three completion stages – Planned, Done, and Rolled Over.
Consider the following situation:
Team Apprentice
Sprint 1
| Planned | Done | Rolled Over |
| 2 | 2 | 5 |
| 5 | 3 | 8 |
| 3 | 13 | |
| 13 | ||
| 8 |
As we can see above, the performance at the end of Sprint 1, out of the 31 story points planned by the Team Apprentice; only 18 story points have been completed. Of the other two, story point 5 has a 95% completion, and story point 8 has a 35% completion.
When calculating velocity in Scrum, only two stages are taken into account – either 0% completion or a 100% completion. That would mean the velocity for Team Apprentice in Sprint 1 is 18. The completion rate of story points 5 and 8 are NOT taken into account.
The velocity of a process in its entirety is calculated in the same manner for each of the sprints and their velocity in individual cases.
For instance, let us say the Team Apprentice has been at a stage where the performance has been as here below:
Sprint 1 – 18 (as we have already found above)
Sprint 2 – 28
Sprint 3 – 18
Sprint 4 – 36
The velocity of the scrum project as a whole would be an average of the velocity of all the sprints included. In our case, the velocity of the project would be 25, which is the average of 18, 28, 18, and 36.
What is the use of Velocity in Scrum?
Well, as a general rule, Velocity in agile systems has always been used as a means of measuring the productivity. That would be a good option in making predictions about the completion of a project. However, experts claim that if you are doing it, you need to exercise caution.
It has been stated that Velocity can be a good measure of the quick glance at the performance of a team. However, it does not give you access to the complete information about the project as a whole. That would mean your predictions would not necessarily be genuine.
Though we have learned how to calculate velocity in Scrum, it can work best with the stable teams that have proved their efficiency.
Does the Maximum velocity of a project in Scrum translate into maximum productivity?
Well, that isn’t a truth. At least not always. Asking a team to maximize velocity can indeed result in bringing in the precisely opposite results. The teams can – in such circumstances – skip the bugs found, leave the acceptance testing, reduce the collaboration levels, and indulge in similar activities just to complete a sprint and not pay much attention to the functionality.
The right option should be to opt for an optimal velocity than focussing on the maximum velocity.
In fact, the right way to adopt in how to calculate velocity in Scrum would be to ensure that at least 3 to 5 sprints have been completed in a project. That would be helpful in having a better visibility with respect to your project progress and help you plan the future sprints more diligently.
The measure of velocity in Scrum can also be helpful enough in understanding whether you are under or over planning your sprints. The rule of thumb would be that the number of user stories taken up during each of the sprints will NOT be more than the average velocity of the past sprints.
How can you use Average Velocity in Agile Development?
Well, there are several advantages of using Velocity as a measure of project development. Of course, as we stated before, it cannot be a prime measure for project performance in more ways than one.
A few of the applications you can put Average Velocity in Agile development can be put to good use can include:
Release Planning
You can plan your release schedule. For instance, if you are planning to release a new product and have been in the process development for the same, you will have an idea into when you can release all the features of the final product. Having a knowledge of the average Scrum velocity can be helpful in estimating what time it will take to release all the features.
Sprint Planning
Like we stated above already, knowledge of an average velocity would be quite helpful in planning future sprints. It will help you make sure that the sprints are not over or under planned.
Velocity can be an essential metric in Scrum, but should not be taken as an ultimate goal. It should only help you in achieving a few internal calculations and need not be a sole measure to arrive at the total performance of your projects.
Add Comment