Make Agile Teams Work Properly: How to Measure a Velocity
Several years of active use and growing popularity of Agile have shown that it is possible not only to increase the productivity of the development team’s work but also to measure it with the help of an index called velocity.
In this material we would like to study the subject of the velocity in Agile in great detail – we consider the main purpose of this metric and its measurability. Also, in our article you will find practical suggestions on how to increase and improve the velocity value of your own project development process.
The true definition of Agile velocity
Before the consideration of the features of Agile practices, let’s remember the process of a classical project development. As it is commonly known, the initial part of such an approach to project creation is a detailed work planning. Usually, it has a lot of aspects, related to the functionality planning, accurate analyzing, testing, documenting and a final confirmation. Although it becomes clearer that this classic does not meet the relevant trends – all these preparatory activities and other assistant procedures require a lot of time and human resources and make the entire product creation rather expensive and impractical.
Against the background of such an active extinction of a classical way of the project creation, Agile techniques and tools are becoming even more popular and really profitable. All the contained processes are absolutely reasonable, and every element included in the work process has its own mission and value. So in Agile it is always possible to make up a proper calculation of the needed resources and expected efforts. There is one great tool that helps specialists with determining the right speed, intensity and approximate labor costs – it calls velocity.
To put it simply, velocity implies the ratio of the development team efforts to perform of a certain work scope to the duration of their work. The value of velocity is measurable and can be expressed in the form of a number or a percentage index of the team’s work effectiveness for a certain periodic interval.
As usual, velocity has a more accurate result of its measurement during several intervals of Agile project production that are called sprints or iterations. Also, the velocity data is perfect to be used in further work planning for new projects.
How the velocity can be evaluated
As we mentioned before, the velocity is a kind of the metric that allows professionals to estimate the speed of execution of a certain amount of work in accordance with a certain project. In some cases, the obtained data may be useful for estimating costs for similar projects, or it can also be applicable to even different project portfolios.
There are several methods of the velocity measurement, and let’s start with the most obvious.
The first velocity measurement way is based on the number of the tasks finished in one sprint. As you know, Agile methodology implies the breakdown of the entire work on the project into several sprints, and each sprint, in its turn, contains a certain number of tasks that must be performed without fail. Therefore, the more such completed tasks, the better the velocity index is for the team.
Here are two lists of the tasks: the one contains the planned tasks, another one consists of finished tasks. As it can be seen, the development team has quite good results in performing tasks in sprints. Their average velocity index for four sprints is 92% what is normal.
The second way is the percentage of those tasks that were planned but not completed during the sprint for some different reasons. This velocity measurement method is exactly the opposite of the first way in the context of the results evaluation. That is, the lower the percentage of unfinished tasks, the better it is for the team and for the development process at large.
We can observe the number of tasks that were canceled and have become unfinished during several sprints. It also should be noted that there are so-called rolled-over tasks – those activities and tasks that were not performed in the previous sprint and moved to the current sprint. This practice is not good because some of such rolled-over guests imply really necessary things to do and should be implemented at a certain time. So the index and the number of rolled-over tasks can also affect the final result of the velocity.
Tips on how to improve and save an excellent velocity
Well, we know what the velocity means for the proper Agile project development work processes. And now it is a great time to receive some handy tips in order to make the velocity metrics better and higher – we are ready to share it with you!
- When planning a project and pre-calculating the required resources, you should always draw on the experience of previous projects. It will be appropriate to note that every particular project requires a personal approach to its implementation, Nevertheless, it will never be superfluous to take into account some key points and be prepared for certain working conditions in advance.
- Make more tasks and complete even more of them! It may look paradoxical but it is true, but there is one moment: try to make up your tasks more simple and easier for their finalization. As you know, every task in Agile can be formed as epics that, in their turn, consist of their subtasks (user stories). So it is a good tone for every developer to create a lot of simple tasks and implement each of them faster, more effectively, and without a hitch!
- The velocity of every team also depends on the collaborative relationships between the members. So try to be more responsive and conscious in communication with colleagues, and you will probably achieve smooth and well-coordinated teamwork.
Today we have done one great matter: we have learned that velocity plays a crucial role in the entire project development process. It is a good way to analyze resource allocation efficiency and the way of team management.
We would also be glad to know your opinion about the necessity in velocity measuring. How do you identify the productivity in your project development processes? And do you think that velocity is the right metric? Please write to us about it the comments of the article!