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 workYes ... and across all Sprints. Velocity is a long-term measure,
> 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".
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 theI would be curious to see a thoughtful description from you on what
> concept of velocity.
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
Ron gave me a good suggestion once. -- Carlton (banshee858)
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.