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

Re: Scheduling Defect Fixes

Expand Messages
  • kbs_kulbhushan
    Hello Roy, I think the velocity is the ability to deliver on the Done definition of tasks. So, if a defect found is not covered under Done it is a new
    Message 1 of 347 , Feb 1, 2011
    • 0 Attachment
      Hello Roy,

      I think the velocity is the ability to deliver on the "Done" definition
      of tasks. So, if a defect found is not covered under "Done" it is a new
      feature, otherwise it is a "Not Done" feature which cannot count towards
      velocity.

      I agree there will be bugs that will slip through, but again "Done"
      definition decides their fate. In our case we consider all P0,P1,P2 bugs
      as part of "Done" criterion that should be fixed ASAP and the effort
      spent on them rightfully reduces the velocity. We do not take credit for
      things "Not Done".


      Regards,


      --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...>
      wrote:
      >
      >
      > 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.
      >
      > Regards,
      > Roy Morien
      >
      >
      > To: scrumdevelopment@yahoogroups.com
      > From: lists@...
      > Date: Mon, 31 Jan 2011 13:46:03 -0500
      > Subject: Re: [scrumdevelopment] Scheduling Defect Fixes
      >
      >
      >
      >
      >
      >
      > Charles,
      >
      > 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
      > ----------------------------------------------------------
      >
    • 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.