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

Re: [scrumdevelopment] Re: Should I assign Story Points to bugs?

Expand Messages
  • Ron Jeffries
    ... Yes. The work of fixing defects distorts the picture of progress. It slows us down. The solution is not to measure it and estimate this work. The solution
    Message 1 of 347 , Jan 14, 2011
    • 0 Attachment
      Hello, Roy. On Friday, January 14, 2011, at 3:33:44 AM, you wrote:

      > If we don't think this way, then velocity becomes a measure of
      > what we have achieved, and what we are likely to be able to
      > achieve, ignoring the work needed to fix bugs. Which is certainly
      > going to distort estimates of completion dates.

      Yes. The work of fixing defects distorts the picture of progress. It
      slows us down.

      The solution is not to measure it and estimate this work. The
      solution is to eliminate it.
      > I can't see why there is this opposition to counting work done to
      > fix bugs as part of the teams achievements. Bugs are a fact of
      > life, even when we try to reduce them towards zero, and bugs take
      > time to fix, and therefore affect how much the team achieves in
      > deliverable work.

      Defects are not a "fact of life". They do not drop as the gentle
      rain upon the code beneath. Each defect is the result of flawed work
      -- mistakes -- on the parts of one or more people. Each defect is
      capable of being made less probable -- very likely 10x to 100x less
      probable -- by the specific ways the team works. See me after class
      for a list of some of the ways that are particularly helpful.

      Scrum requires that the team produce a //shippable// increment of
      code in every Sprint. Not every few Sprints, not after five really
      grueling Sprints at the end of the project. Every Sprint.

      > Taking the last paragraph of Jack's message as a discussion point
      > ... We estimate that the team can deliver 20 Story Points in the
      > next Sprint (based on the historically calculated velocity).
      > During the sprint we discover some bugs in what we have been
      > developing (in the sprint). We fix them because we don't want to
      > deliver buggy software. This takes some time and effort. This
      > affects our ability to complete all the User Stories. That will
      > affect our update of the velocity measure, somehow.

      Yes. If we spend more time fixing defects, we will deliver fewer
      completed stories. Velocity declines due to doing any kind of work
      that is not implementing stories. It would also decline if we spend
      more hours playing Doom.

      End of "Story". Velocity, counted as stories /Done/, correctly
      records all forms of wasted time, as well as our general capability,
      just by counting the stories.

      We are interested in Done stories. We count them as good. We do not
      desire defects. If we know during the Sprint that a story we are
      working on is defective, we do not demonstrate it, and we do not
      count it as done. Our velocity declines immediately, because we
      didn't get that one done.

      If somehow a story slips out and then a defect is found, that story
      has already been recorded in velocity. Velocity is artificially
      high. What should we do? One possibility is to reduce our progress
      bar by that amount, and insert that story back when and if it is
      fixed. That might be more accurate but it is not necessary.

      All we do, instead, is count only the stories done next time. Time
      spent fixing the broken one does not count. Our progress line drops
      by one story, staring now. The line was artificially high for a
      while, but now it is back in line.

      Note that the defect may take less time than it took to build the
      story wrong, or it may take more. Either way, the time necessary to
      complete the story correctly, and the number of stories completed,
      is back in balance with respect to that story. No estimation is
      requiree, no rationalizing about why we should treat what is
      obviously waste as if it were somehow a good thing.

      Just count what's done. Time spent fixing bugs is waste, and it will
      be shown by the amount of work done being reduced.

      > If we can still deliver what we selected, then fine, no affect on
      > velocity. If it does reduce velocity (by a little bit, because
      > velocity is essentially a moving average) this merely acknowledges
      > that the team achievged a certain amount of work, albeit a little
      > less than before. If we find bugs from previous sprints, then we
      > must make a decision about fixing them. We acknowledge that some
      > bugs are high priority, and some can be left on the queue until
      > later. So if we make a User Story of them, and deal with thatn
      > User Story in the normal way, we will prioritise bug fixes
      > appropriately, and not rush off to fix unimportant bugs, or delay
      > fixing important bugs. One way or the other, we will expend work
      > time and effort to fix them, which should impact velocity.

      If a decision is made to fix a defect, then that decision should be
      handled as if it is a story, that is, it should come in through the
      planning session. It should not be accounted for on the product
      burndown as if it were new accomplishment, because it isn't new
      > If I accept Ron's new view, that we make User Stories all of the
      > same size, such that they are capable of being completed in 1 day,

      -- not what I said, I'm rather sure --

      > then we still have no great problem here. If a few small bugs are
      > found, they can be grouped into a User Story that will take 1 day
      > to be done. A big bug may need a lot more analysis and be split
      > into more than one User Story. Ron's 'new view' is just another
      > way of calculating velocity, in my view.
      > Again, I ask, where is the problem?

      I really don't know. Here's an attempt:

      Extreme Programming, specifically the C3 project, specifically Ron,
      Chet, and Ann, introduced the notion of velocity in Extreme
      Programming Installed, ca. 2000 C.E.

      We invented it. We're here to tell you what it is, and why it is
      what it is.

      Velocity is /defined/ as the number of stories the team completes
      per unit time. The notion is specifically designed not to be "the
      amount of work" the team completes, because the focus should be on
      what the customer (product owner) wants.

      (It is perhaps worth mentioning here as well, that "story" is an
      idea from XP also. A story is something that the customer (PO)
      wants in the system. A feature. Somewhat like a PBI.)

      We use velocity for two purposes, once of which is primary: Project

      Project Velocity is the rate, in stories per week or equivalent, at
      which the team is producing done stories.

      In XP, mind you, all stories have complete unit tests and
      automated acceptance tests. They are really done. And when, as
      inevitably happens, a defect slips through, an XP team examines
      its process and practices, determines what tests and other actions
      would have prevented that defect, writes those tests, takes those
      actions, and ups its game.

      They do this because velocity is a measure of //done stories//,
      and anything less makes it a measure of stories that may or may
      not be done. That's not as useful a measure.

      Project Velocity = stories per unit time. Punct, Schluss, Neue Absatz.

      There is another slightly useful application for velocity, the
      number of stories done: it can be used as part of making the team's
      commitment for the upcoming Sprint.

      We should note here that Scrum does not ask the team to attain some
      velocity. Scrum asks the team to //commit// to the Sprint backlog.

      You can use the amount of stories done in the past as part of
      deciding how much to commit to. It is not wise to treat this number
      as a large component of the decision, as there are many more
      influences on how much work the team will get done.

      In Sprint planning, velocity is therefore only somewhat useful, if
      it is useful at all.

      Now then. You express repeated concern that somehow, fixing defects
      is a good thing and needs to be taken into account in velocity. The,
      pardon the expression, error in this thinking is that fixing defects
      is //already// taken into account in velocity, that is, the number
      of stories done.

      It is trivially true that if the team is working on a lot of bugs,
      then they won't get many new stories done. In such a Sprint, their
      project velocity will go down, and it should go down, because they
      are progressing more slowly toward whatever the sum total of
      features needed for release may be.

      Velocity already includes work spent fixing defects. It also
      includes time spent playing Doom, or snuggling in the closet.
      Velocity is the work actually done.

      Therefore no other activity, no matter how important, can be treated as
      adding to velocity. Counting any other activity makes the measure of
      true progress, stories completed, worse, not better.

      Velocity is stories done per unit time. And that's all there is.

      ------- Pause to Breathe, and Think --------

      Now then. We might ask "shouldn't we account for the time spent
      doing other things, like fixing defects?" Perhaps we should: it's
      sometimes useful. We should also, perhaps, account for time spent in
      all hands meetings, or working on Project Beta instead of this

      Sure. If it's significant, account for it. I like a swim lane
      diagram for that, or a bar chart.

      Still, none of this other work is "stories". None of it. Yes, it's
      important. Yes, we might want to account for it. It might be useful.
      But it's not stories, and therefore it isn't velocity.

      Ron Jeffries
      Logic is overrated as a system of thought.
    • 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.

        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.