InfoQ

News

Is Velocity Really the Golden Measurement?

Posted by Mike Bria on Jan 21, 2008 05:28 PM

Community
Agile
Topics
Delivering Value
Tags
XP ,
Retrospectives ,
Continuous Improvement ,
Value & Metrics ,
Planning
Recognized XP thought-leader, consultant, and author J.B. Rainsberger asks teams to consider if they may be giving agile development’s golden metric – velocity – a bit more credit than it deserves. In a recent article Rainsberger presents his case on velocity and effective agile team measurement, illustrating it in terms of home budgeting.
Think about budgeting your expenses at home: you know how much you actually pay for some expenses like car payments, mortgage or rent, insurance … there are other expenses that vary from month to month: food, clothing, entertainment, communications … [and] there are still other expenses that you just can’t foresee. You are injured in an accident and rack up $20k in hospital bills; this is the year out of the last ten that you finally need new shingles on the roof; you find out your son needs braces.
He observes this home budgeting truth -- that “there is no typical month” -- to be a lot like agile development and our use of velocity:
This is also why you cannot rely on velocity to plan far ahead: there is no such thing as a typical project or even a typical iteration.
This being the case, might it not be important for teams to spend less energy on scrutinizing velocity, and more time thoughtfully identifying areas of waste the team can benefit most from by eliminating? J.B. describes an experience with this, again in 'personal finance' terms, as follows:
We measured our actual spending, we looked at those numbers to identify waste, then we eliminated it. We did not waste effort staring at our budget [or, in agile terms, velocity], wondering how accurate it was, wondering how realistic it was, desperately trying to spread not enough money over too many expenses.
Basically, J.B. encourages teams to trade off some of the energy they spend contemplating velocity to focus more on asking questions that enable them to measure, pick, and eliminate the things they spend time on that no-one actually values. Said another way, the message here can be interpreted as a reminder for teams to make sure they’re being diligent about including good retrospectives as part of their normal iteration cycle.

Click the green tags below for more on the closely related InfoQ topics of retrospectives, continuous improvement, and kaizen.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

3 comments

Reply

Velocity measurement is not that useless either by Vikas Hazrati Posted Jan 23, 2008 12:09 PM
Re: Velocity measurement is not that useless either by Mike Bria Posted Jan 23, 2008 2:54 PM
Re: Velocity measurement is not that useless either by J. B. Rainsberger Posted Jan 24, 2008 1:51 PM
  1. Back to top

    Velocity measurement is not that useless either

    Jan 23, 2008 12:09 PM by Vikas Hazrati

    I would agree with the author that Velocity might not be the best measurement however on a tangent I believe that the velocity figures over a few iterations let you focus your energies in the right direction.
    For example consider this

    There is a team of 6 members which has velocity figures of
    It 1 - 12
    It 2 - 10
    It 3 - 9
    It 4 -7

    then looking at the figures iteration on iteration, you would try to do a deeper analysis to understand what is wrong. This would be similar to the news story www.infoq.com/news/2007/12/static-code-analysis... wherein the velocity would give you just visible information whereas a deeper analysis would bring out the root cause.

    Vikas Hazrati
    vikashazrati.wordpress.com

  2. Vikas --

    Thanks for the response, I fully agree!

    Cheers!
    --MB

  3. Back to top

    Re: Velocity measurement is not that useless either

    Jan 24, 2008 1:51 PM by J. B. Rainsberger

    I agree that velocity itself is not a problem; however, when we measure velocity without analyzing how to eliminate waste, the impact is largely negative: we reduce the discussion to "how to go faster", as if typing speed were the bottleneck. Unfortunately, not enough teams reach for the deeper analysis, and if a team chooses not to analyze their situation more deeply, then I'm not sure they should measure velocity at all.

Exclusive Content

Clojure

Rich Hickey discusses Clojure features and syntax, example code, functional programming, concurrency semantics, transactions, software transactional memory, agents, implementation and pain points.

Composite Oriented Programming with Qi4j

We introduce the concept of Composite Oriented Programming, and show how it avoids the issues with OOP and reignites the hope of being able to compose domain models with reusable pieces.

Dan Farino About MySpace’s Architecture

Dan Farino talks about the system architecture and the challenges faced when building a very large online community. Dan explains how a .NET product scales on hundreds of servers.

Principles and Practices of Lean-Agile Software Development

Alan Shalloway, CEO and founder of Net Objectives, presents the Lean software development principles and practices and how they can benefit to Agile practitioners.

The Maxine VM

Bernd Mathiske discusses Maxine VM, Java compatibility, swapping major VM components, research areas, Object handling, code examples, optimizing compiler, snippets, bytecode generation, JNI and JIT.

Joe Armstrong About Erlang

Joe Armstrong speaks on various aspects of the Erlang language, presenting its roots, how it compares with other languages and why it has become popular these days.

The Limits of Code Optimization: a new Singleton Pattern Implementation

The java double-check singleton pattern is not thread safe and can’t be fixed. In this article, Dr. Alexey Yakubovich provides an implementation of the Singleton pattern that he claims is thread-safe.

Pressure and Performance – The CTO's Dilemma

Diana and Jim talk about patterns observed in CTOs' activity. CTOs emerge as real people caring for other people in their organization, and are put under a lot of pressure and constraints.