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

Should I assign Story Points to bugs?

Expand Messages
  • charles_bradley_scrum_coach
    Mike Cohn posted a blog post on assigning Story Points to bugs. Here is his post:
    Message 1 of 347 , Jan 6, 2011
    • 0 Attachment
      Mike Cohn posted a blog post on assigning Story Points to bugs. Here is his post:

      http://blog.mountaingoatsoftware.com/should-story-points-be-assigned-to-a-bug-fixing-story

      I hold a different view, actually based on his writings and definitions.

      I'd be interested in other folks' thoughts. I know we've litigated this before, but thought since Mike recently posted it on it that it's worth discussion.

      Charles

      In Scrum, Should I assign Story points to bugs?
      By charlesbradley

      First a definition.

      Bug – Any behavior of the system that either violates an acceptance test, or is unacceptable system behavior that cannot practically be covered by an acceptance test(for example, aesthetics issues, or legacy bugs). Another way of saying this is any behavior that is inconsistent with previously well understood requirements or acceptance tests.

      This definition is useful when deciding whether something is a bug or an enhancement.

      So, I break bugs down into the following three categories and assign points as follows:

      1) Legacy bugs
      I define a "legacy bug" as any bug that was introduced prior to the team adopting Scrum. Those go on the backlog as user stories and are estimated in points and prioritized by the PO.

      2) Scrum Era bugs
      Any other "bug", introduced since adopting Scrum, is fixed within one sprint of it's discovery(this sprint or next) and no story points assigned, unless both the PO and dev team agree to defer the bug beyond that next sprint(Deferred bugs). If either the dev team or PO chose to have the bug fixed this sprint or next, then the bug appears as a task for the sprint, and is estimated in hours.

      3) Deferred bugs
      These go on the backlog and are estimated in Story Points and prioritized by the PO.

      While this logic is somewhat complex, all other solutions to the "should I assign story points to bug fixes" are also complex, and usually have much larger risks of bad effects.

      Some subscribe to this theory that "bugs can't be well estimated" theory. I don't. Here's why.

      1. I encourage team members to take some time to investigate a bug, up to an hour to estimate a bug that appears to be nasty. This helps reduce estimation inaccuracies.
      2. I encourage teams to then "inspect and adapt" on sizing bugs, just as they would for User Stories.
      3. If the team still can't be terribly accurate after a few iterations, then I would probably just encourage them to spend more time investigating nasty bugs to obtain a better estimate — this would be an extreme situation in my opinion(very low quality product). Note that they can only investigate for an estimate, the time is not meant to spend diagnosing or fixing the bug.

      Some teams try to set aside a set amount of time each sprint for fixing bugs, and assign story points to that effort. I also don't agree with that, as I feel it hinders transparency and makes it too easy for teams to sweep new bugs under the rug. "We'll have time to fix this later in the bug fixing sprint or in the bug fixing time-box next sprint."

      Having said all of the above, while PO's are certainly allowed to prioritize bugs into sprints, the dev team is also allowed to pick any bug it feels needs fixing (whether it be on the backlog or not), and bring that into the sprint as a task (they gain no story/velocity points for this, regardless of whether the bug was on the backlog or not). Only the dev team can decide how much product backlog to bring into a sprint, so if they decide to spend ~ 50% of their sprint bug fixing things not prioritized by the PO, so be it, but it will be visible because their velocity will be lower.

      So, in short, Legacy and Deferred bugs can be fixed either:
      a) When they are prioritized into the sprint because the PO perceives business value gained (story points added into velocity), OR
      b) When they are brought into a sprint by the dev team because the dev team perceives value, and no story points are added into velocity as a result of fixing these bugs.

      According to Mike Cohn's User Stories Applied :
      "…the developers will estimate how much work they'll be able to do per iteration. We call this velocity…"

      Further if you measure velocity in User Story Points, then each User Story must be
      "…valuable to either a user or purchaser of a system" (also from Cohn's book)

      So, velocity is meant to be an estimate of a team's iteration capacity to deliver User Stories that are of value to users and stakeholders outside of the dev team. I believe the above strategies that I describe do just that.

      I could be wrong though, and I encourage others to let me know if they think I am!
    • 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.