Forums

By posting to our forums you are agreeing to the Forum terms of use.
What to do when Bug is raised which is highest priority
Last Post 30 Jan 2014 12:37 AM by Domingo Carpenter. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
bigmealy
New Member
New Member
Posts:3
bigmealy

--
24 Sep 2013 09:01 AM
    Hi,

    I am trying to implement Scrum for a software project, and a bug has arisen which the product owner identifies as more important than anything else, including items in the current sprint.

    What would people recommend be done in this scenario?

    There are about two days remaining in the current sprint, but the product owner is keen to get this bug resolved as it is holding up users of the previous software release.

    Any advice greatly appreciated.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    24 Sep 2013 09:57 AM
    The team need to work on the bug, and explain to the Product Owner that the planned Sprint Goal is likely to be compromised as a result of this action. It sounds as though the PO already knows this.

    Alternatively, the Product Owner has the option of terminating the Sprint now, working with the team to release the maximum value possible from the work that has been completed, and asking the team to use the remaining portion of the timebox to work on fixing the defect.

    Terminating a Sprint is a drastic option. It usually makes more sense to work on the bug and revise the Sprint Backlog accordingly. The Sprint Backlog is essentially a forecast; it is understood that unplanned critical events can occur mid-sprint and that teams must accommodate them. The important thing is to make sure that the root cause of the defect is understood so that the team can adapt accordingly, and thereby make similar problems less likely to happen again. The Sprint Retrospective is a suitable inspect-and-adapt event for this purpose.

    The Bradley Bug Chart goes through these scenarios:

    http://www.scrumcrazy.com/One+way+t...t+in+Scrum
    Dave
    New Member
    New Member
    Posts:2
    Dave

    --
    24 Sep 2013 10:10 AM
    Given that you are near the end of your Sprint, I would suggest not terminating the Sprint as you probably achieved some value of completing some of the stories if you have been managing work in progress successfully. Getting any value from the Sprint, is better than delivering no value.

    If you read the beginning of the Sprint, and it would compromise their entire Sprint then I would advise looking into terminating it if it made sense...

    Just my $.02
    Sandeep Kamat
    New Member
    New Member
    Posts:21
    Sandeep Kamat

    --
    29 Jan 2014 03:07 PM
    I agree if the PO has raised the bug with highest priority then it needs to be fixed in the current at the risk of not completing some of the backlog items. Given that you are the tail end of your sprint you are probably working on relatively lower priority items and moving them out wont be an issue.
    However a few thing ...
    1) In spirit of the Scrum transparency the PO should provided enough context as to why the defect is high priority.

    2) Ideally defect prioritization should be a joint effort . What worked best for me was the case when I had a weekly meeting where all the defects in the backlog were reviewed . The meeting was attended by PO, SM , tech lead, SMEs , person who filed the defect and any one else who might help clarify the priority of the defect. The meeting helps in clarify the source of the defect as well as cost benefit analysis for the PO and then a joint decision was taken when to fix it or defer it to next sprint.

    3) Verify that it is really a defect. Sometimes an enhancement or even product feature is disguised as bug. Again (2) above will help in clarifying this.

    4) The effort is small enough. Most defect should not take more than few hours of dev time to fix. If its more then that probably its a missed requirement
    Domingo Carpenter
    New Member
    New Member
    Posts:3
    Domingo Carpenter

    --
    30 Jan 2014 12:37 AM
    I would suggest not terminating the Sprint as you probably achieved. If new sprint update is released then check out what is new in this. Follow Scrum roles and fix this bug first this is very important to implement Scrum for software.
    You are not authorized to post a reply.


    Feedback