Here are some pointers when it comes to different approaches to handling bugs in scrum:
- 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. If you create an individual user story for each bug then the ‘real’ stories will quickly become obscured.
- Explicit time in each sprint reserved for fixes is fine if done in a way that is visible for the product owner. To keep them on the same page as everyone else, bugs should be mentioned during the daily Scrum meeting and the discussion about bug fixes should occur during the sprint review.
- Placing the whole backlog in a bug tracking tool leads to the same set of problems as in point (1. Furthermore, most bug trackers are not designed to be used with Scrum, so using them 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 into a low-level task (describing a particular bug) or meta-tasks (reserving a given number of hours for general bug fixing). This way the product owner has visibility and the burndown chart can appropriately reflect progress.
Just remember to mercilessly close all "bugs" that are actually new features and instead create new backlog items for them. Also make sure that all the bugs reported against the current sprint are fixed before the sprint is over so the sprint can be considered as done.