RE: [scrumdevelopment] Scheduling Defect Fixes
- Ron, I am unable to provide the treatise on velocity that you ask for. In fact, I don't even see the relevance of doing it.
In my various readings about agile development, I have developed the view that velocity is a figure that is calculated essentially as the moving average over time of the team's output, often or usually, but not always, counted in terms of the quantum of Story Points of the User Story estimates for the User Stories delivered by the team during sprints. The view is that if the team managed to deliver that much functionality, measured in Story Points, in the past, then they are likely to be able to do it again in the future, all other things being equal.
By treating bug fixes as work to be done, and that requiring time and effort by the team, then I can see absolutely no reason, or no point even, in excluding them from the 'effort count' ie: velocity.
I frankly cannot see how this is so fundamentally at variance with the XP definition of velocity, which is (found in 10 seconds on the eXtremeProgramming.org website) :
"The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration. It's just that simple."
It does not wax lyrical about 'done', or about 'double counting credits' or etc etc. It is a simple, straightforwartd, understandable statement of what velocity is.
Fixing defects is work done ... wasted work, i admit, but, work done nonetheless.
Did you write this, Ron, or was it someone else who did not understand the nuances and deep meaning of the term.
> To: email@example.com
> From: ronjeffries@...
> Date: Tue, 1 Feb 2011 07:33:09 -0500
> Subject: Re: [scrumdevelopment] Scheduling Defect Fixes
> Hello, Roy. On Tuesday, February 1, 2011, at 3:13:44 AM, you
> > "velocity is roughly the team's capacity to accomplish work
> > within a Sprint" ... yes, I agree.
> > The bit I don't get is "If you've estimated the work to fix
> > defects, you should /subtract/ that from the available capacity."
> > ... Why? The time and effort in fixing the defects is part of the
> > team's capacity to accomplish work. Fixing the defects is work. If
> > you have no defects to fix (highly desirable, of course), then the
> > team's total capacity to accomplish work will be spent on new
> > development. BUT if they have defects to fix, then they cannot
> > accomplish that same amount of new development, although they are working to capacity.
> > What you say is correct only if the definition of velocity is
> > "velocity is roughly the team's capacity to accomplish NEW work
> > PREVIOUSLY NOT ATTEMPTED, THAT IS DIRECTLY RELATED TO USER
> > REQUESTS FOR NEW FUNCTIONALITY, within a Sprint".
> Yes ... and across all Sprints. Velocity is a long-term measure,
> after all.
> Since features are what we like, that's what we measure. Since
> defects are something we dislike, we chart the metric so that the
> charts look worse in the presence of defects.
> > This is not, in my view, the definition, purpose and use of the
> > concept of velocity.
> I would be curious to see a thoughtful description from you on what
> you think the definition, purpose, and use of velocity might be.
> Historical connection to its origin in Extreme Programming, and
> justification for any proposed deviations from those ideas, would be
> a bonus.
> Ron Jeffries
> Ron gave me a good suggestion once. -- Carlton (banshee858)
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
> <*> To visit your group on the web, go to:
> <*> Your email settings:
> Individual Email | Traditional
> <*> To change settings online go to:
> (Yahoo! ID required)
> <*> To change settings via email:
> <*> To unsubscribe from this group, send an email to:
> <*> Your use of Yahoo! Groups is subject to:
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.