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.
Mike, this is one of the reasons that i think using Cycle Time is more effective than using Velocity. Sure, the numbers can still be gamed, but it seems to me that it's harder to do so.
To put it in the form of a user story:
As a Program Manager, I want to know how long it will take from the time I request a feature to the time it is deployed in production, so that I can drive features that bring value to the company, as quickly as possible.
That is certainly an approach we are going to explore. I think lean, value streams, TOC are all solutions to the velocity problem in the enterprise. I want to build the argument by exploring where velocity works and where it doesn't. It's all about using the right tool in the right situation.
Well it's going to beat the waterfall approach to estimating any day …
We also try to 'calibrate' baselines acros teams. Each team has picked stories for each card (1,2,3,5,etc) which they estimated like that and also still felt like that after implementing the story and these are visible on the wall.
Next week we're experimenting with an all team all PO 30 minute high energie estimation session, if this works out the idea is we do this every week for 30 minutes hopefully making this a fun part of the week and taking it out of the already relatively long sprint planning meeting.