Re: Should I assign Story Points to bugs?
- 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.
--- In firstname.lastname@example.org, 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.
> Roy Morien
> > To: email@example.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
Although, this is not Twitter. I really want to do a +1.>>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.
Echoes my thoughts completely. Won't have been able to put it better myself.