Software development teams are often measured by their velocity. This metric is also known as the number of story points a team completes in an iteration. Some companies use sprint velocity as a stand-in for productivity and quality of code, which can lead to some rather serious abuse.
Here are 3 different ways the velocity metric can be abused.
-
Velocity as a team comparison metric
This is one of the most common abuses. Teams will often look at their velocity relative to other teams’ velocity. When you consider that working in different time zones can have a significant impact on your productivity, then this may not be a good approach.
In addition, measuring something like average velocity per developer (as opposed to an average across all developers) can be misleading, since it can mask the fact that some developers are slow while others are fast.
-
Velocity as a performance metric
The fact that developers are often measured by their velocity can lead to teams engaging in a herd mentality. They will often consciously or subconsciously try to keep up with the rest of the teams. These kinds of pressures may force teams to cut corners, especially when dealing with risky code changes.
Using stories as a proxy for user value can also mask potential risks associated with development activities. You can easily perform a set of activities that looks like you are creating value. When in actuality, it is not true value at all. Therefore, it is important to consider the risk of the story, not just its value.
-
Velocity as a predictor of project delivery date
Velocity is often used as a metric for predicting project delivery dates. This has some major problems. The first, and most obvious, is that the team will attempt all kinds of tricks in order to appear to be getting more value done. It is far easier to increase velocity on a project than it is to actually deliver value.
It is also important to consider how long it takes a developer to complete each story, not just their velocity per story. You will find that some stories are much easier to complete than others and that the time difference will have a significant impact on the overall velocity of your team.
Another problem is burnout. Some teams will work at a very high pace for several iterations. Then, they will suffer a large amount of burnout and productivity loss and need to take some time off to recover. This can easily result in missed deadlines if you rely on velocity as a predictor of project delivery date.
