Skip to main content

What to do when Bug is raised which is highest priority

Last post 01:37 am January 30, 2014 by Domingo Carpenter
4 replies
10:01 am September 24, 2013

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.


10:57 am September 24, 2013

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+to+handle+Bugs+and+Production+Support…


11:10 am September 24, 2013

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


04:07 pm January 29, 2014

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


01:37 am January 30, 2014

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.