Learn How to Make Best Use of Velocity in Agile

As many of you know, Creating efficient timelines is a must for time critical projects. Not only does it help the development team define their day-to-day tasks but also helps them chart out task priorities for each sprint or iteration. In Agile, timelines are calculated by considering velocity. 

According to Scrum, Inc., team velocity is a “measure of the amount of work a team can tackle during a single sprint and is the key metric in Scrum”. When you complete a sprint, you’ll total the points for all fully completed user stories and over time find the average number of points you complete per sprint.

Past velocity can be used to make future estimates and prevent further issues and risks like not hitting a deadline or rushing the development process. Note that each team has its own velocity so you’ll have to measure it separately.

Team Velocity = Total Story Points Completed Per Sprint / Number of Sprints

Why team velocity tracking matters

The point of tracking velocity isn’t to generate a nice-looking report for your boss. Measuring team velocity gives you a realistic understanding of how long team members will need to complete certain tasks based on their complexity.

Universally, we tend to overestimate the amount of work we can complete in a given time period. Measuring actual velocity – how much work we really get done – enables us to plan more accurately, making us much more likely to achieve our goals!

Velocity is an extremely simple, powerful method for measuring the rate at which scrum development teams consistently deliver business value. Calculating velocity helps the team arrive at timelines and define how soon the project can be delivered.

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. To measure the progress of your agile teams, Velocity is a great metric tool that is applied. In layman’s language, velocity refers to the amount of work done by the team in a given amount of time. There are various parameters of measuring velocity for a team. It depends on whatever unit of measurement you use to calculate your work. It helps in

• Predicting how much scope can be delivered by a specific date.
• Predicting a date for a fixed amount of scope to be delivered.
• Understanding our limits while defining the amount of scope we will commit for a sprint.

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. 

Velocity is a key feedback mechanism for the Team. It helps them measure whether process changes they make are improving their productivity or hurting it. While a Team's velocity will oscillate from Sprint to Sprint, over time, a well-functioning Scrum Team's velocity should steadily trend upward by roughly 10% each Sprint.

It also facilitates very accurate forecasting of how many stories a Team can do in a Sprint. (In Scrum this is called using Yesterday’s Weather.) For forecasting purposes the average of the last three Sprint's Velocity should be used. Of course, this means it takes three Sprints of experience for a Team to determine its Velocity accurately, which can sometimes be difficult to explain to impatient stakeholders.

Velocity can be measured at several levels: 

- At the individual task level  (also called cycle time)—How long does it take the Scrum team to turn over individual tasks? A Control Chart, shown below, is a visualization which shows velocity by task. Circles that “float up” on the chart are tasks that took a long time to complete and should be investigated. Progress within a sprint can also be visualized by a sprint burndown chart.

- At the sprint level : How many story points is the team managing to complete per sprint? A higher number indicates more functionality delivered to users. However this metric assumes the team is adhering to their “Definition of Done”; criteria for releasing a user story, which might include code review, testing, documentation, etc.

- At the epic or release level : An epic or release burndown chart in Scrum tracks how much of the originally planned scope of the epic or release has been completed. It’s very important to track scope creep: additional requirements or user stories added during the Scrum lifecycle, after the start of the release. Below is an example of a burndown chart for an epic which indicates work added during the cycle.

Many believe that metrics are useless, but unless you measure, how can you systematically improve or know how you are doing?

Velocity is an important metric used by Scrum Masters and Product Owners to track their team’s progress and ensure a successful project. Velocity helps to determine project timelines and allows Product Owners to give accurate estimates without falling into the trap of overcommitting.  

Measuring your team velocity doesn’t mean much if you aren’t increasing that velocity. Ideally, when you increase Scrum velocity, you’re more quickly releasing features, shortening the time to value for your customers and increasing equity value for the company.

You cannot rely on the numbers provided by agile velocity. Rather it is the trends that will ultimately measure and facilitate efficiency. Thus, velocity cannot be used and relied on as an efficiency goal. It is important to understand what this means.

Without Velocity, Release Planning will not be smooth. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.

To conclude, velocity is not an end goal but as a result. It should be used for continuous improvement of the team and not for any other purpose. The moment this metric is used for another purpose, the teams will cease to reap its benefits and will ultimately result in losing focus on their agility goals.

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.edureka.co/blog/velocity-in-agile/
4. https://www.orangescrum.com/blog/5-easy-ways-to-improve-Sprint-velocity-in-scrum-teams.html
5. https://study.com/academy/lesson/scrum-velocity-definition-calculation.html
6. https://www.wrike.com/scrum-guide/faq/what-is-velocity-in-scrum/