Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Oct 06, 2009 — Enterprise Agile Planning expert

Velocity in the Enterprise, Part 2

Enterprise Agile Planning

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.

The post Velocity in the Enterprise, Part 2 appeared first on VersionOne Blog.

More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us