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

75707Re: [XP] Estimation and load factor

Expand Messages
  • Pieter Nagel
    Jul 2, 2003
    • 0 Attachment
      On Wed, Jul 02, 2003 at 08:47:40AM +0200, Piergiuliano Bossi wrote:
      > Pieter Nagel wrote:

      > >You decide, subjectively, whether the widget was more work than the
      > >bank account.
      > >
      > Right, but this is true whether you are using gummy bears, ideal time,
      > actual time, etc.

      That's my point. Since "effort" is a vaguely-defined concept, any attempt
      to measure it will have subjectivity lurking somewhere. If you think you
      got rid of it, you just swept it under a rug somewhere.

      > The not yet addressed challenge is to discover a way to measure
      > delivered value. Through ROI? SIP? Acceptance tests? Function points?
      > Something else?

      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

      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.

      If a better technique for estimating customer value comes along, I'll jump
      at it. I agree with you that finding such a measure is a fascinating,
      valuable question. A lightweight measure that does it's job good enough
      without requiring too much effort for the benefit, I mean.

      > But of
      > course, when you want to measure productivity you are only interested in
      > considering actual time, aren't you?

      I think we keep missing each other. For me, there is not much value in
      knowing it took 34.7615 minutes to write:

      class SimpleAndClean:
      def doSomethingWellDefined(self):
      return whatever

      one day, and then the next day knowing it took 12.0543 minutes to write:

      class StupidAndUseless(GratuitousBaseClass1, GratuitousBaseClass2):
      def lookMaICanWriteSomeRealHairyCodeIfIWantTo(self):
      # copy and paste duplication
      # copy and paste duplication
      # copy and paste duplication

      the next day. Sure, I got the actual times down pat, but what's the real
      value of one versus the other? As I said, in the end, you have to
      subjectively compare them.

      > * WriteEmails 2 / 4 ==> completed
      > * FeedingCat 1 / 1 ==> completed
      > * PlayingWithKids 2 / 3 ==> completed
      > * WashingDishes 1 / 0
      > * Cooking 2 / 0
      > My velocity was 5, instead of 8 as I would hope from the planning game.
      > Is it understandable?

      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.

      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.

      Actually, you are convincing me that estimating in terms of real hours
      could work, at least just as well as gummybears, for many purposes; maybe
      better, for other purposes. I'm trying to wrap my head around how it would
      pan out in practice.

      > You should ask yourself if your way to measure gummybears is the same as
      > 6 months ago.

      Well, the deeper question is why the heck do I even *care* about 6 months
      ago? :-)

      If one always keeps improving, and if you are better than last month, or
      at least not worse than last month - is that not "good enough"? Within a
      short 1/2 month timespan, gummybears tend to be "the same enough". Within
      a 6 month window, sure, they drift.

      But the same applies to estimating in real time: surely a team can know
      the value of the hours they spent last month vs this month "good enough"?

      > Again, productivity is a completely different issue and should be
      > addressed on the business value side.

      I agree, in the ideal.

      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 e t e r / |/ a g e l
    • Show all 17 messages in this topic