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
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us