Best ways to fit bug fixing into a Scrum process? [closed]

Question

I have been studying and reading about Scrum in the last few days and reading about Sprint Planning and tasks. One problem that popped into my mind is how to deal with bugs in Scrum. Henrik Kniberg lists some ways of dealing with this issue in his very nice book Scrum and XP from the Trenches :

1. Product owner prints out the most high priority Jira items, brings them to the sprint planning meeting, and puts them up on the wall together with the other stories (thereby implicitly specifying the priority of these items compared to the other stories).
2. Product owner creates stories that refer to Jira items. For example “Fix the most critical back office reporting bugs, Jira-124, Jira- 126, and Jira-180”.
3. Bug-fixing is considered to be outside of the sprint, i.e. the team keeps a low enough focus factor (for example 50%) to ensure that they have time to fix bugs. It is then simply assumed that the team will spend a certain amount of time each sprint fixing Jira- reported bugs
4. Put the product backlog in Jira (i.e. ditch Excel). Treat bugs just like any other story.

Is this really something that needs to be decided per-project basis or are there better solutions? I can think of problems with each of those approaches. Is there a hybrid coming from those approaches that works best? How do you handle this in your projects?

Answer 1

This is a very good question and I have some observations when it comes to different approaches to this problem.

1. Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.
2. Explicit time in each sprint reserved for fixes is fine if done in a way that is visible for the product owner. Bugs should be mentioned during the daily scrum and discussion about bugs fixed should occur during the sprint review. Otherwise the product owner won't be aware of what's going on in the project.
3. Putting the whole backlog in bug tracking tool leads to the same set of problems as in 1. Moreover most bug trackers are not designed with Scrum in mind and using them for this purpose can be painful.

The solution we found the most satisfying was to put a single user story called "Tickets" or "Bugs" on every sprint. Then such a story can be divided either into low-level tasks describing a particular bug (if known during planning) or meta-tasks reserving a given number of hours for general bug fixing. This way the product owner has visibility into the process and the burndown chart reflects the progress.

Just remember to mercilessly close all "bugs" that are actually new features and create new backlog items for them. Also make sure to fix all the bugs reported against the current sprint before the sprint is over in order to consider the sprint as done.