There’s been a recent discussion on the Scrum Development list about velocity - the Agile term that represents ”the sum of the estimates of the stories [points] that were completed in an iteration.” Within the Agile community, velocity is the primary metric used to report progress and success. There’s no other single Agile metric that gets as much attention, discussion and scrutiny as velocity.

While following the velocity discussion, I wondered, “Is velocity really the best metric for Agile teams and organizations (including Product Owners and ScrumMasters) to focus on?”

After some thought I concluded No.

Why, you may ask?

Answer this question: What’s most important for the people financing your project-product-service? Is it the benefits they expect from the solution, such as increased revenue, market share or operational efficiencies (we’ll call this business value)?

Or is it the estimation accuracy of the team working on the solution (velocity)?

Let’s try another: What’s most important to your customer, the person exchanging money for your project-product-service? Is it the benefits they expect from the solution, such as ease of use, reduced manual data entry or improved forecasting accuracy (we’ll call this customer value)?

Or is it the estimation accuracy of the team working on the solution?

See where I’m going here...

I’m not saying velocity is useless and we shouldn’t track it. I track it on my projects and agree it helps with capacity planning future iterations and investigating “what happened” for particularly good or bad iterations. It can also help manage expectations about what’s realistic in a defined time period for a team.

Unfortunately though, velocity has become the primary metric used by Agile teams for measuring success. I think this is a shame. Instead of focusing teams and organizations on estimation accuracy we should be focusing them on value delivered.

There are ways to measure value, as illustrated in my recent article. But this requires focusing on the real stakeholder objectives that represent business and customer value. It requires augmenting story-centric requirements approaches with value-centric requirements approaches. It requires measuring success in terms of value delivered.

Kai Gilb’s recent work on the role of the Value Product Owner illustrates nicely how Stakeholder and Product Values can be used as the primary measures of success and integrated into the Scrum process. Instead of just planning and prioritizing at the user story level, the Product Owner plans, prioritizes and tracks results at the Stakeholder and Product value levels, thus getting a more holistic picture of success (business and customer value delivered).

I’ve also recently discovered James Shore’s term “value velocity”, which uses customer-defined “value points” at the story level to estimate the value before a story is scheduled for a release/iteration. Value velocity is therefore reported as the number of value points completed in the release/iteration.

While I think this is an improvement over not attempting to track value at all, I would argue 1) actuals at the stakeholder/product level are better than estimates at the story level and 2) actuals can be obtained without too much difficulty - if you quantify success and failure using scales and meters that are relevant and affordable (based on your budget). It’s doable with a little effort and I would argue is well worth the limited investment required.

So the next time you find yourself using velocity, think for a second, “Do I mean estimation accuracy or the value of what was delivered?”. If it’s the latter, then perhaps velocity isn’t the right metric.