Agile development cycles, with a product increment delivered at the end of each iteration, have been proven to increase productivity and maximize value. Customers can see new features and releases more frequently than in a traditional development project, where the product is released only at the end.
However, to plan, estimate and reach goals as per schedules, you should be able to gauge how much work the team can complete in every sprint. This will help to optimize resources and get the work completed as per timelines. This is where calculating the Scrum velocity plays a significant role.
Velocity, as the name indicates, is a measure of the progress of work executed by the Scrum team. It can be defined as the ‘rate at which Scrum teams consistently delivery product value’. It indicates how many products backlog items have been completed, as per the Definition of Done, during a sprint by the Scrum team.
A team that can accomplish a higher velocity will be able to deliver more software functionality and create greater value for customers.
The velocity is a helpful predictive metric that is used to determine how much scope can be delivered by a particular date, or for fixing a date by which a specific amount of scope could be delivered. It helps the team to understand what is possible, and what is not, when committing to timelines during a sprint.
Velocity is a key metric in Scrum and can be calculated using amazingly simple guidelines. While it can also be measured using ideal days or hours, the most simple and efficient way of calculating velocity is using Story points.
It is important to note that points from incomplete story points are not used, and only those story points that are deemed to be complete in all respects can be used to calculate the velocity.
Here is a simple example that shows how the velocity can be calculated.
Remember, we had said that a story point that is not 100% done cannot be considered to calculate the velocity. Hence, only X and Z are added up, which gives us 3+2= 5 points as the velocity of this iteration.
If there are another 30 story points to be completed, we can assume that the same team will require 30/5= 6 more iterations to complete this amount of work.
A team that has already completed several iterations will have a good ability to predict the release and product completion schedules. By viewing the velocity report, they will be able to plan future projects with accurate timelines.
This, of course, assumes that the team members stay the same for the upcoming projects as well. In case some of the members are switched around, this exercise of computing the velocity would have to be redone during the first iteration. Again, if the sprint duration changes the estimates will again undergo a corresponding change.
For teams that stay together, it is easy to track the effort that has been reported as being completed during each sprint. They will also be able to predict and estimate the effort that can be handled in future sprints.
A velocity chart is a visual representation of the Effort (in terms of Story points) on the Y axis, plotted against the Sprints on the X axis.
Let us understand how to read the Velocity chart with the help of an example.
In the diagram below, the team was less productive in Sprint 2, with 29 story points getting completed against 38 in Sprint 1 and 3, and 39 in Sprint 4.
As we have already mentioned, only the story points that were 100% completed during the sprint can be used to calculate velocity. Even if there is just a bit of work left to be done for a story point to be completed, it will be rolled over to the next sprint.
Continuing with the same example, here is how we calculate the average velocity.
At the end of four sprints (see image below), this is how the story points looked. The average velocity can be calculated as (38+ 39 + 38 +39)/4 = 38.
With a backlog of user stories mapped out for the remaining increments, it becomes extremely easy to calculate how much time the team will require to complete the final product release.
Using Velocity Charts comes with advantages as well as disadvantages.
As we have seen, by calculating the project velocity we can chart out the time required for the team to complete the entire project. Regardless of the size of the project, this method will be a fairly accurate representation of the schedules and you can determine when the rollout of the final product is likely to happen. The velocity metric is very important when planning budget and resource allocations for the project.
How can a team use the velocity metric to calculate estimates?
A Last Word!
Velocity charts are one of the most useful metrics that an Agile team can follow to track work progress and team capacity. We hope we’ve been able to give you the insights you need to perform velocity calculations and use them to work out project estimates.
Your email address will not be published. Required fields are marked *
Systems thinking is a popular buzzword today. We h... Read More