Velocity in the Enterprise, Part 2

One of the advantages of using a software solution for tracking team velocity is that it is pretty easy to roll the data up. The idea is that you have lots of individual teams that all contribute completed features to a larger project or program. But… if I know that comparing velocity across teams is problematic… does the idea of rolling velocity up even make sense? Consider this… let’s say we have a feature that could take a single developer 3 days to finish. One team might think this is a pretty small item and give it a point value of one. A neighboring team might consider a similar feature a 16. Its the same amount of work for both teams its just that the second team has a different numbering scheme for the work.

When the features are complete, and you roll-up the data across the teams, you’d burn down a cumulative 17 points for completing both features. Looking at the data over time, and considering the law of averages, the roll-up does work… as does the burndown… it’s just that you risk the team with the larger point values obscuring the progress of the team with the smaller point values. Because this doesn’t result in a very clear picture at the portfolio level, many organizations start normalizing velocity across teams to try to tell a better story. By normalizing, I mean they come up with a standard definition for the size of a single story point. Having this baseline understanding takes some of the messiness out of rolling up velocity but the approach isn’t without some risk itself.

Normalizing velocity can lead to bad behavior. Why? One of the main reasons teams use velocity is to abstract the estimate from any notion of time or effort. If you map a story point to a unit of time… even temporarily…. it can lead managers to start resource planning based on points delivered. It can also create unfair comparisons between teams because it doesn’t account for team dynamics in the performance equation. It also doesn’t take into consideration the accuracy of the estimates and all the stuff we know contributes to making estimates uncertain. That said… even with those risks… normalizing velocity is almost a necessary first step when trying to assess progress on a multi-team program. Its a risk I’m willing to take.

Okay… given all that… even if we correctly understand velocity and are open to normalizing the numbers… that is still not enough to make velocity a meaningful metric in the enterprise. For a velocity roll-up to work, we have to make sure two key things are in place:

1. The sub-teams have to be completely nested underneath the program or project in a many-to-one relationship.
2. Each team has to be working on a feature that is relevant at the program or project level. It can’t take more than one team to deliver a feature.

We’ll talk about these constraints more in my next post… for now… give all this some thought and let me know what you think. Stay tuned.