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

50239Re: [scrumdevelopment] Re: Scheduling Defect Fixes

Expand Messages
  • Vikrama Dhiman
    Feb 2 10:55 PM
    • 0 Attachment
      >>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.

      Although, this is not Twitter. I really want to do a +1.

      Echoes my thoughts completely. Won't have been able to put it better myself.
       
      Thanks

      Vikrama Dhiman
      ================================================================
      Personal Blog : http://www.vikramadhiman.com/
      My Blog about all things Agile : http://agilediary.wordpress.com/



      From: George Dinwiddie <lists@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wed, February 2, 2011 11:09:28 PM
      Subject: Re: [scrumdevelopment] Re: Scheduling Defect Fixes

       

      On 2/2/11 5:48 AM, Ron Jeffries wrote:
      > Hello, kbs_kulbhushan. On Wednesday, February 2, 2011, at
      > 12:23:59 AM, you wrote:
      >
      >> Does this make sense?
      >
      > Not really, but it was a delightful demonstration of how many
      > numbers can dance on the head of a pin.

      It (and the length of this thread) is a great illustration of why I
      recommend that teams not get too wrapped up in estimation. They start
      looking for numerical precision, and that starts consuming the energy
      that could be put toward accomplish goals.

      I suggest that the primary reason for estimating stories & tracking
      velocity is to help the team decide how much work they can do in the
      next iteration. I've found that developing clear acceptance examples
      (a.k.a. tests) helps them do that much better than more time spent
      honing estimates.

      I suggest that the secondary reason for estimating stories & tracking
      velocity is to help the PO predict how much functionality can be done by
      a certain date, or how long it will take to build a certain amount of
      functionality. When doing so, one has to remember that these are just
      estimates, no matter how much work you put into them. You need to allow
      some leeway for the things you don't know and can't predict. You need
      to track actual progress, and give that more weight than any predicted
      progress. And you need to measure actual progress in ways that don't
      mislead you. The more calculations you put in, the more likely you're
      going to fool yourself.

      - George

      P.S. Remember that the abbreviation for "estimation" is "guess."

      --
      ----------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------


    • Show all 347 messages in this topic