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

Re: [XP] Estimation and load factor

Expand Messages
  • Piergiuliano Bossi
    ... Ok! ... Peter, if you really think that gummybears map in any way to customer value that s ok for me, but I have to disagree, that is to say that
    Message 1 of 17 , Jul 5, 2003
    • 0 Attachment
      Pieter Nagel wrote:

      >Your point seems to be that if we ignore customer value, measuring "work"
      >done per time is a bad time to measure productivity because a team that is
      >coding rocket-science proppellerheadish frameworks that do not support any
      >customer requirement is just wasting time, not being productive. If so, I
      >agree.
      >

      Ok!

      >However, I also feel that given the choice between tracking *nothing* on
      >the one hand, and tracking "gummybears completed per iteration" on the
      >other hand (with the assumption that the team is, in good faith, trying
      >to deliver value and that) - I feel that is a better measure of
      >productivity than not measuring it at all. Not ideal, but maybe good
      >enough for many purposes.
      >

      Peter, if you really think that gummybears map in any way to customer
      value that's ok for me, but I have to disagree, that is to say that
      gummybears, like actual time, measure only effort. You may use it to
      check your estimation accuracy (my position is that in this sense actual
      time works better), you may use it to plan work for the next iteration
      ==> they are perfect for this! But you should avoid using them trying to
      evaluate productivity.

      In order to evaluate productivity you need an independent, objective
      measure of value such that: P = V / E, where P is Productivity, V is
      Value and E is Effort.
      Ok, I know, put it this way is a little bit simplistic but it gives an idea.

      [snip]

      >So at the end of the iteration you some up the estimated value of each
      >completed task to get velocity? That's how gummybears work, too.
      >

      Exactly!

      >My concern is, suppose for the next iteration you get similar tasks again.
      >Since the team tries to get their estimates to match reality, they say:
      >"Ok, we know writing emails actually takes 4 pomodori, so lets estimate
      >them as such next time round."
      >
      > * WriteOtherEmails 4 / 4 ==> completed
      > * FeedingCatAgain 1 / 1 ==> completed
      > * PlayingWithKids 3 / 3 ==> completed
      > * WashingDishes 1 / 0
      > * Cooking 2 / 0
      >
      >For a velocity of 8, but same amount of work in same time.
      >
      Wrong: according to Yesterday's Weather now you should plan 5 story
      points, nothing more, but if you were working with pomodori you would
      have planned 8 pomodori again. Ok, this is another story.

      That's the rule of the game, as I understand it. Velocity & Yesterday's
      Weather are not there to express productivity in some way, but only to
      let you plan effectively.

      [snip]

      >But don't gummybears *rougly* correlate to customer value delivered? Much
      >much more so than, say, using the humidity of the development room as a
      >rough estimate of productivity?
      >

      I don't know, I have never measured productivity in terms of humidity of
      the development room. I fear that in my office it would be a disaster. :-)
      I think that gummybears *ROUGHLY* correlate to complexity, that is to
      say to effort.

      Ciao, Giuliano



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