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

Re: Should I assign Story Points to bugs?

Expand Messages
  • JackM
    The only time one should assign story points to bugs is for legacy bugs. There is definite value in this for Product Owners - specifically quality in this
    Message 1 of 347 , Jan 13, 2011
    • 0 Attachment
      The only time one should assign story points to bugs is for legacy bugs. There is definite value in this for Product Owners - specifically quality in this case. Bugs found and fixed during the sprint should not be assigned any story points as this will affect the velocity in such a way as to provide false sense of how fast the team is moving.

      Great thread
      Jack
      www.agilebuddy.com
      blog.agilebuddy.com

      --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
      >
      >
      > < The primary value of velocity is to know [roughly] when we will get somewhere. >
      >
      > Yes, true, which I feel is just a rewording of what I said ... velocity measures how much we can achieve in a sprint, based on past experience. Therefore we can estimate when we will get somewhere.
      >
      > Finding and fixing bugs is part of the effort that we have previously expended, thereby affecting how much we can achieve in a sprint. Therefore, velocity is affected when we fix bugs, and therefore when we can get somewhere will be affected.
      >
      > Everything that you have said about developing the most important stories first etc. is perfectly reasonable and true, but not germane to the discussion. What is germane is how much we can deliver by a given future time, ie: when we will get somewhere ... and the time necessary to fix bugs is part of that calculation.
      >
      > Even when we do not count partially completed User Stories we are taking into account the time to fix bugs (finding and fixing the bugs took so much time that we couldn't complete the story, and so it is not counted in velocity, which is therefore lower than if we had completed the story).
      >
      > Albeit not the bugs in previously 'completed' stories.
      >
      > The fact is, fixing those bugs is necessary, but needs to be in an appropriate priority order. This allows us to decide if the bug is important enough to fix now or later. Effort in fixing the bug when we get to it affects velocity. That affects either when we are going to get somewhere, or what we are going to get by the time we get there.
      >
      > So, I guess an amalgam of our two positions might indicate that if we assign Story Points to bugs (and the only way to do this is to have a User Story about the bug) it will result in some impact on velocity. The completed 'bug Stories' will be counted in velocity by being a completed story.
      >
      > Regards,
      > Roy Morien
      >
      > > To: scrumdevelopment@yahoogroups.com
      > > From: ronjeffries@...
      > > Date: Sun, 9 Jan 2011 06:37:14 -0500
      > > Subject: Re: [scrumdevelopment] Re: Should I assign Story Points to bugs?
      > >
      > > Hello, Roy. On Sunday, January 9, 2011, at 12:26:43 AM, you wrote:
      > >
      > > > I made the point, or asked the question, before, why do we calculate velocity?
      > >
      > > In counterpoint to your reply:
      > >
      > > The primary value of velocity is to know [roughly] when we will get
      > > somewhere. Using past velocity to estimate how much work to take on
      > > next week is OK, but it isn't the point. The point is to use
      > > progress to date to predict future progress.
      > >
      > > We have 100 stories done in the past five months. We have 50
      > > stories to do. We'll need another two-and-a-half or three months.
      > >
      > > We have 100 stories done in the past five months. We want to ship
      > > in two months. We'll have about 40 more stories done. We'd better
      > > pick the most important ones, or lean them down to be sure we
      > > cover everything at least adequately.
      > >
      > > Now then, let's see what's up with defects. (There aren't bugs in
      > > programs. There are defects.) Anyway, our topic is whether we should
      > > count story points for defects. Let's think about that.
      > >
      > > If we have [important] defects in ten percent of our stories, then
      > > we really only have 90 done, not 100. And projecting out, we'll only
      > > get about 36 more even that well done. It looks like we'll have 140
      > > stories by the deadline but in fact we'll only have 126 that
      > > actually work. And we'll be out of time to fix the ones that don't.
      > > So if our 14 defective stories each need a half a story's worth to
      > > fix, we need 7 more stories' amount of time to fix them, or about
      > > three weeks.
      > >
      > > So, supposing that we don't start fixing defects until the end of
      > > the seven months of the project, we'll have 14 bugs to fix and need
      > > three weeks to do it. And we say to the boss "Can we have 14 story
      > > points for this work?"
      > >
      > > The boss, rightly, says "no".
      > >
      > > Therefore, defects that we put in should not count for story points.
      > > Instead, we should measure the true velocity, namely the number of
      > > stories we have //working correctly// per unit time.
      > >
      > > Defects selected by the product owner, left over from previous
      > > generations could count as new stories, and for purposes of
      > > prediction, perhaps they should.
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > Any errors you find in this are the work of Secret Villains,
      > > whose mad schemes will soon be revealed. -- Wil McCarthy
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to: scrumdevelopment@...
      > > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      > >
      > >
      > >
      >
    • 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.