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