Back to Forum

Handling an existing bug while working on an Increment

Last post 04:17 pm May 13, 2020 by Ian Mitchell
6 replies
Anand Pandey
09:53 am May 6, 2020

Let us take this scenario - Mid-sprint, Dev Team found an existing while working on a PBI item.

They discuss it with PO and he suggests (a) to let it go for the future or (b) to work on it in this sprint. 

As Dev team owns quality, should they go ahead, create a task, and fix it within this sprint? Or should they listen to PO's 1st suggestion?

What if working on it takes time and will impact the Sprint Goal?

Thomas Owens
02:16 pm May 6, 2020

Talking with the Product Owner is the right thing to do. There needs to be an understanding of what the impact of the bug is, especially if it already exists. Perhaps some of the new development will cause more people to use the functionality and stumble across the bug. The existence of workarounds and how burdensome or effective those workarounds are also has an impact. Maybe the existence of the bug would make the resulting Increment not viable for use.

In an ideal world, fixing a bug would take precedence over any new development. We don't live in an ideal world, though, and all possible work needs to be evaluated to figure out what adds the most value in doing.

Steffen Brümmer
03:20 pm May 6, 2020

I usually ask the team if fixing the bug will endanger the sprint goal. If no, they just fix the bug and everybody is happy ;-).

 If yes, then it's up to the PO to decide about the priority. Most of the time the team can convince the PO to give the fix priority so that no additional technical debt is build up. But sometimes there are valid reasons for the PO and the team to delay the fix in order to achieve other goals first.

Anand Pandey
06:11 am May 7, 2020

Thanks, Steffen and Thomas for your inputs!

Now, if fixing the bug means risking Sprint Goal and not fixing the bug means the increment is not shippable. What should be the stand in that case?

Thomas Owens
09:22 am May 7, 2020

Now, if fixing the bug means risking Sprint Goal and not fixing the bug means the increment is not shippable. What should be the stand in that case?

With that choice, I'd choose to fix the bug and have a potentially releasable Increment.

Ensuring that you have a potentially releasable Increment allows you to have something for the inspection and adaption activities of the Sprint Review. Even though the goal wasn't met, having a useful, working product is more valuable than having a product that doesn't work or isn't acceptable to users.

I would use at least some of the time of the Sprint Retrospective to understand why such a critical bug wasn't detected earlier. It was introduced in the last Sprint or earlier, yet none of the team's quality activities detected it. If the Increment was released, it also wasn't detected by people using the Increment.

Tim Moeker
07:27 am May 8, 2020

Bugs always depend.

If they find a bug in the SBI they are working on, it needs to be fixed, otherwise it is not working.

If it is an existing bug from prior implementations, it is not neccesarily in scope of the SBI. If the SBI can be done and everything works, while the bug is still in other areas, let's have a PBI for an upcoming Sprint. If the SBI does not work, due to the bug, it needs to be fixed, of course, otherwise the SBI cannot be "done".

Ian Mitchell
04:17 pm May 13, 2020

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.