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

Re: [scrumdevelopment] Re: Scheduling Defect Fixes

Expand Messages
  • Ron Jeffries
    Hello, Roy. You really do not want to go down the Technical Stories rathole. Here s why: Technical stories do not work well. The reason is that the Product
    Message 1 of 347 , Feb 1, 2011
    • 0 Attachment
      Hello, Roy.

      You really do not want to go down the Technical Stories rathole.
      Here's why:

      Technical stories do not work well. The reason is that the Product
      Owner must prioritize all work. It is nearly impossible to compare
      the value of a new feature with the value of some proposed
      refactoring, or with upgrading the servers to Version 2.0.3.5.

      The result of this difficulty is dispute, and, for many teams, great
      difficulty in getting "permission" to do technically important
      things.

      Yet, this work needs to be done. One might ask what we do about it.

      First, we express all Backlog Items in terms of user value that the
      Product Owner can understand and prioritize.

      Second, we do as much technical work as we can, as a matter of
      course. For example, all necessary refactoring to put in a new
      feature is done as part of the feature. If we estimate features, we
      include all necessary work as part of the estimate. (As would
      anyone, I hope.)

      The result of this is that there is little or no need for "Technical
      Stories". This is a good thing, because it is so difficult to
      prioritize them fairly.

      One more thing:

      On Tuesday, February 1, 2011, at 9:53:13 AM, you
      wrote:

      > And by including all of them in velocity (because they all require
      > effort to be expended), we can still give an updated estimate of
      > completion time, or features that can be completed by the stated
      > deadline.

      Actually, we cannot. The reason is that working this way, we do not
      have any way of knowing what Defect Stories, and what Technical
      Stories, will pop up. It therefore works better to treat all such
      work as overhead, so that our estimates do not have to be rescaled
      to accommodate this unknown. Instead, if we count only true User
      Stories, velocity predicts directly when all User Stories will be
      done. Everything else is factored out of that measure.

      (This not to say that we should not track that overhead. We should,
      unless it is quite small. I have previously recommended a "swim
      lane" diagram for this purpose.) This makes the information visible,
      but does not contaminate the progress charts.

      > (and we all know this is the bit that varies, sometimes
      > wildly, over time).

      I don't know that. If the completion time or number of features
      possible by a date is varying wildly over time, there is something
      seriously wrong. Common causes of wide variance in velocity include:
      -- changes in team composition;
      -- team working on more than one thread of work;
      -- late or inadequate testing turns up problems late;
      -- high defect injection rate adding unexpected work;
      -- decreasing code quality causing variability in effort;
      -- and doubtless others.

      Each and every one of these makes the Scrum burn charts less useful.
      As such, each and every one represents an impediment that needs to
      be removed.

      Ron Jeffries
      www.XProgramming.com
      Hope is not a strategy. -- Michael Henos
    • Vikrama Dhiman
      ... 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
      Message 347 of 347 , Feb 2, 2011
      • 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
        ----------------------------------------------------------


      Your message has been successfully submitted and would be delivered to recipients shortly.