Loading ...
Sorry, an error occurred while loading the content.

Velocity as a productivity metric

Expand Messages
  • Lior Friedman
    Hi, I was talking with one of my client about ways to judge whether a team is becoming more productive over time. the client is kind of new to agile and they
    Message 1 of 83 , Mar 25, 2012
    • 0 Attachment
      Hi,

      I was talking with one of my client about ways to judge whether a team is
      becoming more productive over time.
      the client is kind of new to agile and they use Scrum as their underlying
      process.

      During the discussion he asked a fairly simple question:
      if we measure velocity and the team we expect the team to improve over time
      would the sprint Velocity would reflect this change?
      or in other words can we use Velocity to measure the team velocity.

      now my gut reaction was no this is not a good idea and i can even name a
      few reason that may cause this not to work.
      However, clearly there is a connection between velocity and productivity so
      in theory this can be used.

      So the question I would like to reflect on is:
      Under what conditions (if at all) can Velocity be used as a productivity
      metric?
      and if if not, why not?


      --

      *Lior** **Friedman*
      Agile Consultant - AUT/TDD Expert | Mobile: 972.52.833.3660 | Email:
      lior@...

      Blog - http://imistaken.blogspot.com

      *P.S. Follow me on **Twitter* <http://twitter.com/imistaken>* &
      **LinkedIn*<http://il.linkedin.com/in/friedmanlior>
      *. See you there´┐Ż*


      [Non-text portions of this message have been removed]
    • RonJeffries
      Hi Adrian, ... Yes. Here s a random thought that I had about how a reduction in cycle time might not be good. Suppose when a feature comes in, we ship the
      Message 83 of 83 , Apr 9, 2012
      • 0 Attachment
        Hi Adrian,

        On Apr 9, 2012, at 8:29 AM, Adrian Howard wrote:

        > However what I'm hearing from Amir (which may, of course, be in my head not his words) is that he's generally in a situation where he's *confident* that a decrease in cycle time is a "good thing". Likewise for increases in cycle time being a bad thing.
        >
        > I don't generally find myself in that place - I'm interested in figuring out one or more of:
        >
        > * How I can do this
        > * Why Amir can do it in his context, and I can't do it in mine
        > * How I'm misunderstanding what Amir is saying (or vice versa)
        >
        > Sound vaguely sane?


        Yes. Here's a random thought that I had about how a reduction in cycle time might not be good. Suppose when a feature comes in, we ship the current software and report the feature done. Cycle time drops quite low. Good, huh?

        Of course we'll have a lot of bug reports. But we handle them the same way: ship the current software and report the bug fixed.

        I'd like to hear from Amir on this one. :)

        Ron Jeffries
        www.XProgramming.com
        If not now, when? -- Rabbi Hillel



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.