Is Velocity Killing Agile?

| by Michael Floyd on Nov 04, 2011. Estimated reading time: 2 minutes |

Writing in his recent Blog, Velocity is Killing Agile, original Agile manifesto signatory Jim Highsmith describes velocity-hungry managers that use velocity as a measure for productivity. “...they are often maniacal about measuring velocity—team velocity, velocity across teams, rolling up velocity to an organizational level or even velocity per developer (yuck)”, he writes.

Highsmith points to velocity being used more and more to measure productivity. It’s easy to guess why. Any measure of productivity that helps you identify what is working and what is not allows you to adjust accordingly. Moreover, velocity information is easily gathered, easy to calculate, and is seen as a measure of volume output. But Highsmith cautions that such a measure focuses too much on the volume of story points delivered. “This volume detracts from the quality of the customer experience delivered and investing in what he calls “the delivery engine.”

Compounding the problem, the Agile movement has focused on high levels of customer involvement—basically a good thing—but we’ve gone too far. A large number of Agilists decry that they can’t get organizations to focus on technical practices—but why should that be a surprise when we encourage product managers/owners to make all the priority decisions and then measure performance using velocity?  We have overcompensated for the lack of customer focus in traditional methodologies—by giving control of prioritization to the product owner/manager.

Highsmith is not the first to question the use of velocity in agile practice. In his blog, Misuse of Velocity in Agile projects, posted last year Mark Levison defines velocity as the amount of work completed by the team divided by the time taken to complete it. He writes “The amount of work is usually measured in Story Points (a relative measure of size).”

Levison talks about the use of velocity to compare the productivity of two teams. But as Levison points out:

Agile/Scrum teams use relative estimation (i.e., is this story/feature bigger or smaller than our standard story?) vs. the traditional approach of absolute estimation. The problem with comparisons, benchmarking, or any other attempts to compare velocity is that my story points ≠ your story points, because different projects use different standard stories. They work in different problem domains, and they have different people.

Scott Ambler also wrote on the subject some years ago about the dangers of comparing velocities between teams, and suggested that you instead calculate the acceleration of each team. Among the advantages that Ambler suggests are that it’s easy to calculate, it’s easy to automate and it’s difficult to game. On the downside, it’s an indirect measure that may dependent on factors that Ambler calls “fudge factors.”

While Highsmith’s title may sensationalize the issue, neither he nor Levison are suggesting that velocity is entirely evil. Highsmith writes that “The proper use of velocity is as a calibration tool, a way to help do capacity-based planning,” Levison suggests that “the real value of Velocity and Release planning is giving the Product Owner a good idea of what can be achieved before the next release.”

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I see velocity cause more stress and fights than help direct projects by J. B. Rainsberger

I recommend against estimating anything smaller than a release = 1 quarter = 3 months. I prefer to put the effort towards finding the kernel of a feature area (now called Deliberate Discovery + Walking Skeleton + the Toyota Version, or Lean Startup) and building that first, then adding the parts that we know we need as we know we need them. I'd rather focus on the question, "Can we afford to continue at this pace?" rather than "When will all this stuff be done?!" I hypothesise that Corporate Types don't trust this in part because they don't have to do it: they're playing with someone else's money. Imagine if they had to plunk down their own money to fund software projects.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss