Vigilance is vital to avoid velocity vices!

 

After daily coordination events (a.k.a. Scrums, standups or huddles), velocity might be the most misused tool by teams new to agile and the stakeholders supporting them. Used appropriately, it can help a team to understand how much work they can complete in a fixed amount of time and thus could be used to forecast when they might be done with a release. However, being able to do so requires that three critical prerequisites are met. If any of these are not, velocity is irrelevant.

The first requirement is that the team composition and capacity should be relatively stable. You might argue that if capacity has decreased, one could pro-rate velocity based on the decrease. This assumes that we have enough capability (skills and experience-wise) across the remaining team members to complete work items, albeit at a slower pace. In the real world, teams often rely on specialists and if any of those are missing, it might not be possible to complete certain work items.

The second prerequisite is that the team needs to be working on the same product. Change those and there is no guarantee that they can continue to complete work at the same pace unless the two products are very similar.

Finally, the relative uncertainty of upcoming work items should be less than or equal to that of recent previously completed work items. If complexity or uncertainty increases over time, velocity cannot be relied upon.

So assuming these three conditions are met, can we breathe a sigh of relief and freely use velocity?

Unfortunately there are still three ways in which velocity data can be abused by stakeholders.

1. Comparing velocity between teams. Regardless of whether you use story points, number of work items completed or some other method to calculate it, it is meaningless outside the context of a specific team working on a specific product. Using velocity as a performance measurement could encourage the wrong kind of behaviors such as neglecting quality, working an unsustainable pace or ignoring tangible business value delivered.
2. Calculating velocity at an individual team member level. Teams complete releases, individuals don't. Measuring velocity at the team member level provides no real value and will just create destructive competitive behaviors within a team.
3. Assuming that velocity will continue to increase indefinitely. It is reasonable to expect that velocity will increase temporarily as a team evolves their way of working. However, it is unrealistic to expect that they can continue to speed up their pace of completing work unless there is either a significant change in the product, their delivery process or the team composition. Any such change would represent a different context which means that you couldn't compare present to past velocity.

Just as with any tool, there is usually one right way and many wrong ways to use velocity.