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

24192Re: Why points are lame...

Expand Messages
  • aldoc_uniblue
    Sep 30, 2007
    • 0 Attachment
      Petri Heiramo:
      > Based on personal observation on our projects, hour estimates have a
      > tendency to err quite a lot. Yet they give the impression of accuracy
      > and validity. Story points don't have such an illusion built into
      > them. They accurately reflect the amount of uncertainty in any
      > estimate. That alone should be a reason for software developers to use
      > them, since so many times estimates are interpreted as commitments to
      > certain expense and effort spent.

      I agree with Petir. Very often, estimating using real time gives the illusion that you can get a pretty accurate estimate of how long something will take.

      However, while time is definate and finite, tasks are undefined and variable. Until one commits to a task, it is very difficult to accurately estimate how long it will take to accomplish. There are many reasons for this including the fact the humans are not machines with a standard output rate, a developer on a task may be called to fix a bug, etc.  (see Mary & Tom Poppendieck "Implementing Lean Software Development:   From Concept to Cash").

      Another reason why developers estimate using story points or as Mike Cohn (i believe it was in his book on Story Estimating and Planning) also calls "Ideal Time" is because humans lack the ability to accurately predict the future (most likely, not even Nostradamus would be able to accurately predict the length of a task :).  As Petri said,  "[story points] reflect the amount of uncertainty in an estimate". This is also why a 4 point story can take 3 days to implement for one story and 5 days for another.

      When teams decompose stories into tasks, they will get a better idea of how long something will take to accomplish in real time given their team's current state. Still, this is not an accurate prediction and can only be based on past experiences, thus the notion of a burn-down chart.

      Aldo Cauchi Savona

      Agile Specialist


      Uniblue Systems Ltd.


    • Show all 185 messages in this topic