PremierAgile

Scrum has become one of the most implemented Agile frameworks among many organizations as it contains flexible and adaptive methods for software development. Any individual who is interested in the Scrum framework has to learn the values and principles of Scrum and also understand how to use the tools and techniques to process the product development. One main concept in Agile used to measure progress is by using velocity. Velocity is a powerful and simple method of measuring how much work is completed by the Developers at a given time and how much value they provide the business consistently. The average number of Product Backlog items that are turned into increments during a Sprint by the Scrum Team may be considered as Velocity. Velocity helps the team to estimate the scope of delivery of the product and helps them to formulate a specific date at which they can deliver the product. It also helps the team to understand their limitations regarding the scope of products and makes them promise only the items that they can deliver during the Sprint. This article focuses on understanding Velocity and measuring Scrum Velocity in detail and explains how to improve team velocity in Agile.

What is Velocity in Scrum?

Velocity in Scrum is a measure of how much work is completed by the Developers within a specific Sprint. Sprints are time-boxed intervals that last about two to four weeks and repeats till the product is fully developed. Work in Scrum is broken down into smaller chunks called User Stories that concentrate on end-user functionality. A numeric value called Story Points is associated with every User Story that estimates the amount of time and effort required to complete a particular User Story. All the Story Points of User Stories that are fully developed and tested are added to get the total amount of work completed by the team in a Sprint. Scrum uses Sprints as a measure of time and does not use days, weeks, or months as a Sprint gives a more accurate estimate of time. The Sprint length is fixed at the beginning of the product development and stays consistent throughout the development process. Professionals may also come across the question of what is Agile velocity. Just like Scrum, Agile velocity is the measure of work done in each iteration and used by the Agile teams to create precise timelines. Scrum Velocity is associated only with the Scrum framework and is derived from the concept of Agile velocity. 

Types of Velocity in Scrum

Scrum velocity has two versions but calculations for both versions are similar. Actual velocity is calculated by dividing the total Story Points completed by the team by the number of Sprints. For instance, if the Scrum Team has finished a total of 80 points over 4 Sprints then the actual velocity of the team would be 20 points per Sprint. This version is more accepted by Scrum Teams and used commonly during velocity calculation. 

The second version of Velocity is known as the expected Velocity where the total estimated Story Points are divided by the number of Sprints. Here, the team estimates the Story Points that it may complete in a given number of Sprints. For instance, if the team decides that they can complete a total of 150 points in two Sprints then, their expected velocity is 75 points per Sprint. This version is not used frequently but may be used to compare with the actual velocity so that the Scrum Master could see whether the team meets up with their commitments. 

How Velocity is calculated in Scrum?

It typically takes an initial few Sprints for the team to figure out a stable Velocity. As understood, the team uses the total number of Story Points completed and divides it by the number of Sprints to get the Scrum Velocity value. The past-record experience could be used to get an accurate value for the Velocity of the team which would help the team to estimate the further Velocity for the Sprints and give the customers an expected completion date. The last three to four Sprint velocity should be used to forecast the upcoming velocity of the team to get an accurate number. The team should not add any incomplete or partially completed work while estimating the Velocity as it creates confusion and does not give a correct estimation. 

Stories that are marked as "Done" must only be considered while calculating the Scrum Velocity. User stories that have even a small amount of work left to be completed must not be considered while estimating the velocity. Teams cannot estimate velocity based on only one Sprint and hence at least 3-4 Sprints should be used to calculate the actual velocity of the team. For example, if the team completes 30, 29, and 31 Story Points in the first, second and third Sprints respectively, then the average velocity of three Sprints is 30. 

Example of Velocity

Here is a step-by-step process of calculating the scrum velocity.

Step 1: The velocity of the first Sprint must be calculated

Suppose the Scrum Team has planned three stories A, B, and C for completion in a given Sprint. The Story Points for A and B are 3 and the Story Point for C is 4. At the end of the Sprint, the team manages to finish A and B User Stories, but the User Story C is completed 70%. While measuring the total Story Points for the Sprint, the team should only consider A and B Story Points as they are 100% completed and should not consider Story Points of C. 

Step 2: This number obtained can be used to estimate the number of iterations needed to complete a particular product. Assuming the velocity of the team remains the same, the total number of Sprints can be calculated. For instance, the remaining User Stories have a total of 80 points then the team may predict that they require more than 20 iterations. (Each Sprint- 4 points divided by total Story Points- 80)

How to Improve velocity in Scrum?

As explained, the velocity of the team estimates the rate at which they can complete work. When a team has a higher velocity, it indicates that they are being efficient and productive. However, one also has to know that one team cannot be compared to the other as the value in velocity is subjective. Hence, while comparing the progress the team has to be compared to itself and how it performed in the past Sprints. Here are few tips that teams could follow to increase team velocity in Agile. 

1. Responsibly using metrics

Every team rates its Story Points differently and making comparisons across teams seems an unreliable way of comparing progress. The same thing also applies to comparing the progress across various projects as there is no standard measurement at which velocities can be compared to. As more data is collected, the metrics are more reliable. Metrics should always be used as a mode to encourage the team and not to apply undue pressure. When unnecessary pressure is applied, the team's productivity may decrease and their morale may be damaged.

Also, the team has to verify and evaluate the metrics properly during retrospectives as they are the basis for the calculation of further Scrum velocities. 

2. Enhance the Quality 

When the team focuses on increasing the quality of work, there would be no need to revise the work in later stages. This leads to higher productivity and the bulk of the work moves towards the initial stages of development. The risk of items that return to the Product Backlog also decreases. Focusing on the quality of the work would also decrease the artificial inflation of the velocity, which means when quality is compromised, the speed may increase but the productivity and return of investment are damaged. 

3. Streamline the testing

A test should be done more than once only when there is a significant reason. The integration and user interface tests should be evaluated regularly. A code need not be retested if it has not changed, as it just consumes time. If the code is already tested in previous iterations, the bugs and issues may have been found and fixed. Testing the features which are required and limiting the test for features that are rarely used would increase the velocity of the team. If a feature is used rarely or never used, it would be no benefit of testing it by dedicating a significant amount of time. 

4. Consistency and Focus must be promoted

The priorities of the task must be decided before the Sprint begins and should not be adjusted as the Sprint progresses. The productivity of the team may suffer if the priorities of items keep changing during the Sprint. Also, if the member multitasks, the result would not be as expected, and a large amount of time would be lost with no work done at the end of the Sprint. Unnecessary changes to the product must always be avoided as they would hinder the progress of the team. If the product scope keeps changing in between the Sprint, the team cannot focus on a particular task. Hence, consistency and focus on one task after the other are recommended for better productivity. 

5. Cross-Training should be encouraged

Bottlenecks and gaps in the structure of the team could be prevented by cross-training, which can also help the team to cover their roles effectively. Team communication can also be promoted by cross-training and everyone on the team could learn all the skills needed in a product development process. Training sessions could be held where external consultants can be hired to increase the skills of the team. They can also give guidance to the team about how to learn the skills, and use them during the process of development. 

Conclusion

Velocity in Scrum is a subjective measure of the rate at which work is being completed in a Scrum Team within a given Sprint. Velocity gives an idea about the speed at which a particular product could be completed by the team. The Scrum framework uses Story Points as an estimation to measure the time taken by a specific User Story. As the team progresses with the work, the velocity value becomes more accurate as the team has more data to calculate. Velocity helps the Scrum Team to keep track of their progress and helps them to perform better at every successive Sprint. Velocity should not be compared across teams or products as the Story Point of each team and product would be subjective. However, velocity in Agile gives an accurate measurement of how much the team could work in a particular Sprint and how many Sprints it may take to complete a specific product.

References

1. https://www.visual-paradigm.com/scrum/what-is-scrum-velocity/
2. https://www.planview.com/resources/articles/lkdc-velocity-agile/
3. https://www.orangescrum.com/blog/5-easy-ways-to-improve-Sprint-velocity-in-scrum-teams.html
4. https://study.com/academy/lesson/scrum-velocity-definition-calculation.html

Useful Links:

A-CSPO Online Training Indianapolis, Product Owner Course Shanghai, Advanced Scrum Master Course Training Bangalore, CSPO Online Certification Missoula, Scrum Product Owner Online Training Qatar, Product Owner Training Boise, Scrum Master Virtual Certification Training Memphis, A-CSM Online Course Tokyo, A-CSM Course Oslo, Advanced CSPO Course Training Jacksonville