Often associated with the Scrum methodology, Agile velocity may be a valuable tool when it comes to tracking the work done by a development team during a sprint and helping to predict the predictability of the next one. On the other hand, poorly used as a performance indicator for management, for example, it can be totally counterproductive.
We’ll enlighten you on exactly what Agile velocity is, what it can bring to your development teams, and what you should not do.
What is Agile velocity?
Velocity is an indicator used on projects managed using an agile method, such as Scrum, for example. Agile velocity makes it possible to determine the effort that a development team is able to provide to carry out the tasks programmed in a sprint. It is expressed in numbers of points.
The product owner places a certain number of functionalities to be done, or items generally formalized in the form of user stories, in the product backlog. The development team assigns each product backlog item (or PBI) a number of points. These points represent both the complexity and the duration of the realization of the PBI, estimated empirically. It is not a linear scale. The Fibonacci sequence is often used.
Also, the values that can be assigned are:
- 1 for an extremely simple task, such as, for example, correcting a label,
- 2, 3, 5 for a slightly more complex task, such as creating a simple entry form,
- 8, 13, 21, 34, 55, 89, 144 if there is not enough information to estimate the task appropriately.
There are several methods of estimation such as t-shirt sizing, for example, where t-shirt sizes are used artificially, or the best known, planning poker.
The Agile velocity of the development team is calculated after a sprint. It is enough to add the values of all the PBIs fully completed and delivered during the sprint. For example, if at the end of the sprint, the team has achieved a PBI with 5 points, three PBIs with 3 points, two PBIs with 1 point, and there is one remaining PBI with 3 points that is in progress – not yet finished, the Agile velocity will be 16 (the last 3-point PBI is not taken into account since it is not yet finished).
But if Agile velocity is calculated only at the end of the sprint, how is it a predictability tool?
In fact, it will take between three and five sprints for the velocity of the development team to stabilize. Sprint 0 is usually complex. It is about getting started with a team whose members do not necessarily know each other or the processes. Velocity is rarely very high. It will gradually increase during the first three or four sprints until it stabilizes. Agile velocity is then optimal and is relatively representative, even if it remains an estimate, of the effort that the team is able to produce during a sprint.
How do you use Agile velocity?
Once Agile velocity is stabilized, it is then possible to predict fairly faithfully the number of points of effort that the team could achieve, and thus optimize the selection of PBIs to be carried out during the next sprint.
The establishment of a burndown chart will highlight the accumulated velocity during the various sprints and the number of points remaining in the product backlog. Thanks to this tool, it will be possible graphically to follow the progress of the developments and to plan the progression of the next sprints based on the average velocity of the development team.
It may be interesting as well to keep a reserve of points that is not directly assigned to carrying out a specific task during a sprint. Indeed, the principle of an agile method is to be able to adapt to change, and it is common for a task to be performed to be only identified during a sprint, or for a change of priority or a technical problem to cause complications. This reserve of points will allow taking into account these various tasks in addition to others without jeopardizing the expected delivery at the end of the sprint.
Once Agile velocity is stabilized, it is then possible to choose the different PBIs that could be tackled in the next sprint according to the points that have been assigned previously. The velocity in the following sprints must be about the same as in the current sprint; it will be possible to plan the content of several deliveries in advance while maintaining the ability to adapt.
It is very important for the velocity of a team to be stable, and for us not to try to increase it permanently. The predictability of sprints is only effective if the velocity does not change, or changes very little. Increasing velocity at all costs while stabilized can only have a negative effect on realization. It will usually be at the expense of the quality of developments and customer satisfaction.
What not to do with Agile velocity!
Agile velocity is an indicator meant only for the development team and the product owner. It is an effective tool for validating the content of a sprint or otherwise revising its planning, but in no event should it be interpreted as an indicator of performance.
Agile velocity should not be used by management. The current excesses observed are the intent to increase it at any price and the competition of several teams.
After a few sprints, velocity will be stabilized, optimal and will provide an indicator of the possibilities of the team. The increase will necessarily be at the cost of the quality of deliverables produced. It is better to focus on the experience and user satisfaction rather than the quantity of features delivered. Increasing Agile velocity at all costs will only distort the indicator, introduce a work pace that is less and less sustainable, and ultimately demotivate the project team. Agile velocity is all the more an indicator of performance that can vary temporarily or permanently depending on the life of the team. Sick developers, training, a change of scrum master or even the integration of minor corrective patches in large numbers are all factors likely to decrease Agile team velocity during a sprint. This decrease in velocity will in no way indicate a decline in productivity.
Velocity is a team-specific indicator, so comparing it to that of another team makes absolutely no sense. The team with a lower velocity may have the impression of having to prove itself or want to increase it artificially by overestimating initial orders, for example. It is therefore likely that one finds oneself with increasing velocities and a real productivity which decreases.
To conclude on Agile velocity
As you can well imagine, Agile velocity is an indicator powered by the development team and intended for the team itself. Used well, it can improve predictability on upcoming sprints. Misused, it can be the source of an increased pressure on the team and its demotivation.
The Nutcache online project management solution provides all the tools needed to calculate and manage the Agile velocity of a development team.
Feel free to take advantage of the 14-day free trial period to evaluate Nutcache.
