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

Re: [scrumdevelopment] Let's Stop Talking about User Stories (Re: Should I assign Story Points to bugs?

Expand Messages
  • Ron Jeffries
    Hello, Adam. On Friday, January 28, 2011, at 6:28:25 PM, you ... Yes, thank you. :) ... Yes. Defects imply that something isn t done (and perhaps putting it
    Message 1 of 347 , Jan 28, 2011
    • 0 Attachment
      Hello, Adam. On Friday, January 28, 2011, at 6:28:25 PM, you
      wrote:

      > Actually, Ron has said that he thinks that bugs do go in the backlog,
      > but that bugs are not the same thing as stories and should be treated
      > much differently.

      Yes, thank you. :)

      > My own opinion is that we should do our best to keep bugs out of the
      > backlog. The difficulty I have with accepting the premise that bugs go
      > on the backlog is that we would first have to take something
      > functional off the backlog that didn't really work. In other words,
      > before the bug goes on the backlog something came off the backlog that
      > was supposed to be done, but it wasn't really done because it had a
      > bug.

      Yes. Defects imply that something isn't done (and perhaps putting it
      back is better than adding a defect in). Neither is good, Neither
      should be business as usual in my opinion (and I'm sure you agree).
      No one has said, quite, that it's business as usual. I feel that
      some have gotten close.

      > This means we have to accept that "done" PBIs can be partially correct
      > and therefore perhaps not valuable on their own. Such things could be
      > PBIs, but they could not be stories. At best they are unfinished
      > stories. I would rather treat such and item as an unfinished story
      > until I was certain that it had no bugs rather than treating it as a
      > "done" PBI plus newly found defects.

      Yes. :)

      Ron Jeffries
      www.XProgramming.com
      If you hear a voice within you say “you cannot paint,”
      then by all means paint, and that voice will be silenced.
      -- Vincent Van Gogh
    • 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.