What is velocity?
Let’s start with the definition of velocity. Velocity is an easy and powerful method for measuring the pace at which scrum teams deliver business value. So, velocity chart allows understanding the amount of value delivered in each sprint by a scrum team. The average amount of delivered value or velocity allows predicting the amount of work the team can complete in future sprints. This is very popular parameter in Agile project management methodologies such as Scrum. Velocity is actually the key metric in Scrum.
In this session, I will focus on velocity charts based on story points. However, the same charts can be built based on task count, business value, hours and so on. Additionally, I will assume that the team works with users stories; however, other work item types can be used to measure velocity.
How to calculate velocity?
To calculate average velocity you need to have a few completed sprints and apply the following average velocity formula:
Velocity = Completed user stories (sum of story points) / Amount of Completed Sprints
I recommend taking last sprints only in order to be have data that are more precise.
Let’s find velocity in the following example:
Team velocity = 14 + 15 + 15 + 17 + 18 / 5 = 16
Many project management and task tracking tools allow building velocity reports automatically. I just created an example in Excel:
Blue bars – sum of story points of user stories taken into the sprint; orange bars – sum of story points of completed user stories.
The purpose of velocity
Velocity is useful when it comes to planning meetings in Scrum. The team can quickly look at the velocity metric and understand how many tasks they can take into a new sprint. Note: velocity measurement should be done on regular basis (for example 1 time per sprint).
Velocity is also very helpful for product owners. For instance, a product backlog includes user stories estimated at 95 story points in total. The product owner knows that the velocity of the team is 16 story points. 95 / 16 = 6. It means that about 6 sprints are needed in order to complete all tasks from the product backlog (assuming that no additional tasks will be added to the product backlog). It worth mentioning that velocity is not exact science. It provides an approximate value, which is normally unstable when the team starts working on a new project and become more stable after a few sprints.
In addition, velocity helps to understand performance of the team. If estimates are stable, meaning that they are made by the same people, those people are constant in their estimates, and the team is stable as well, meaning that there are no changes in the team, the team can understand whether their performance increases or not. Look at the screen where I added trend line, which is based on completed user stories.
Hope this information will help you to work with Agile/Scrum teams efficiently.