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

50153RE: [scrumdevelopment] Scheduling Defect Fixes

Expand Messages
  • Roy Morien
    Feb 1, 2011
    • 0 Attachment
      I still can't see this, George.
      "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".  This is not, in my view, the definition, purpose and use of the concept of velocity.
      But this is, of course, where I obviously differ from some others.
      Roy Morien

      To: scrumdevelopment@yahoogroups.com
      From: lists@...
      Date: Mon, 31 Jan 2011 13:46:03 -0500
      Subject: Re: [scrumdevelopment] Scheduling Defect Fixes


      On 1/31/11 12:55 PM, Charles Bradley - Scrum Coach, CSM, PSM I wrote:
      > I'm curious though.
      > > If you wish to estimate how long they will take to fix, feel free
      > > to do so.
      > No mention of adding defect fixing to your velocity calculation? Even to
      > mention that the practice is controversial? Maybe you were going for a
      > "basic" or "high level" description of the solution.
      > To the OP(the one who asked about scheduling bugs into Scrum), my
      > comment is this: Be careful about adding your defect fixing estimates to
      > velocity(which is a User Story concept). That practice is controversial,
      > and the main risk is that you do not want to decrease transparency by
      > lumping material amounts of "defect fixing efforts" in with "new
      > functionality efforts that add value to the system." The best solution,
      > as Ron mentions, is probably to reduce defects to such a small rate that
      > there is no material amount of defect fixing time. There are other
      > solutions, but they get down "into the weeds" in Scrum and User Story
      > philosophy.

      Yes. The way I express it is that velocity is roughly the team's
      capacity to accomplish work within a Sprint. If you've estimated the
      work to fix defects, you should /subtract/ that from the available
      capacity. And always remember that the goal is to produce working
      software, not to "get credit" for story points.

      - George

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org

    • Show all 347 messages in this topic