Velocity is a metric that is used in agile projects to represent how fast a team is building the software. Velocity is number of story points (or what ever the unit of estimation is) finished in an iteration. I have seen some managers using this metric in ways that is not intended for. I am going to take a crack at explaining what it should be or shouldn’t be used for.
What does Velocity represent?
Before you know what velocity should be used for, you need to understand what exactly it is. I think it is lot more loaded than it appears to be. One should know deeper about velocity to use it properly. Velocity in a single iteration doesn’t mean much, whereas an average velocity over several iterations could answer few questions. For example, if a team’s average velocity is 10, it means that the team is likely to finish rest of the development work of that release or project or chunk of work at that velocity. The reason I said it is “likely” because there are several factors that could make this statement wrong. It is critical for the team to understand these factors so that they make right decisions.
Team’s knowledge of the domain
The team with the higher knowledge in the domain would build the software faster. If the project is brand new and the team that is going to work on the project doesn’t have much knowledge about that domain, the velocity would be less. Velocity will improve as the team is learning more about the domain. On the other hand if the features are enhancement to the existing system, the team probably is more familiar with the system and will have higher velocity. In either way the average velocity could be established after few iterations.
Team’s technical skill level
Team’s technical expertise plays a vital role in how fast they can build the software. This is not only the knowledge about technology and tools being used, also the architecture of the system being worked on. This would have the similar effect as we discussed above.
Clarity of requirements for the stories
If the stories are well defined, the team will have less impediments and the work will be done faster. Lot of time requirements aren’t clear at the time of estimation as well as some times at the time of building also. Team needs to work through the unknowns and resolve them on a daily basis. This will slow down the process and will reduce the velocity. It is important to solidify the requirements before the start of the iteration for the team to maintain the velocity.
Changes to team composition
This question arises very often that what happens to the velocity if we added a member to the team. Is it going to go up right away? I don’t think so. When a new member is added, it is likely that the velocity will go down first. This is because the current team members need to train the new member. It will eventually go up. It is hard to say how many points it will go up by. It depends several factors. This includes the experience level and attitude of the new member. Since agile teams are collaborative, each member would have an impact on the whole team. For example, the new member could be a leader and inspire every one in several ways. This will have a positive effect on the team. On the other hand the new member could be a whiner and cause head ache to the whole team in which case the velocity is likely to go down.
Support activities team performs.
If team is engaged with support activities like productions tickets and fixing bugs, their velocity of developing software will go down. If these supporting activities are not controlled, eventually the velocity will go down significantly. As the team is building more code, it could increase the supporting activities also. This could be because of cutting corners while developing new features or improper implementation of the features themselves. It is critical to identify this (Technical Debt) and correct it as soon as possible. Read my blog post on Technical Debt.
Corporate culture is a big factor in the team velocity. This includes the processes, policies etc. If the team has to work in a tightly controlled framework, the value added tasks would be less and hence the velocity will go down. So, the team’s velocity is the points per iteration in that corporate culture. Everything else being the same, if the same team is working in a different corporate culture could increase or decrease the velocity. The organization needs to understand this and change the culture such a way that it fosters agility across the organization.
The velocity of a team represents its productivity considering all the factors talked above.
What should you use velocity for?
In general, the team should watch and learn from the velocity. Velocity should only be used for planning purposes. Completion of a project could be predicted if the team’s long-term average velocity is known. However , this prediction would be more accurate if the factors affecting the velocity stay relatively stable.
What shouldn’t you use velocity for?
Team member velocity shouldn’t be calculated from the team’s velocity.
In a true agile team, more than one member work on a story. A developer, tester, possibly a DBA and a SysAdmin spend their time to complete the story. It would be inaccurate to try to compute an individual member’s velocity.
Velocity shouldn’t be used for performance reviews.
If velocity is part of the performance evaluation process, that could lead to inflated estimates by the team. Team performance should be evaluated using some other means like peer review or 360 degrees review.
Don’t expect team to have the average velocity in every sprint.
Product owners need to understand that the average velocity is not guaranteed in each and every sprint. If the team’s average velocity is 10 points, they shouldn’t wait to plan mandatory 10 points in the iteration. Features should be planned well ahead of their required delivery date.
Past velocity can’t be used as basis if the context changed.
If the teams velocity can’t be used as basis if one of the factors discussed above changed. For example a team’s velocity in one project can’t be used as basis for a different project unless same team is working on the new project and they have same level of knowledge about the new project.