Is Velocity Killing Agile?

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.”

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.