How do bugs fit into Scrum

Zero bugs; it's the nirvana we all strive for as software professionals, it's also unfortunately a myth. The only way to write code without bugs is to not write code. All software has bugs, it's simply of matter of how hard you look to find them. You'd like to think that the top companies somehow have come up with a way to create bug free software. After working at two of the biggest, Intel and Microsoft I can tell you they haven't figured out how to ship bug free code either.

Scrum isn't a magic process that doesn't have to deal with finding and fixing bugs. Like waterfall it focuses on the delivery of the product and with the product comes bugs. If you're using scrum how do you account for fixing the bugs that exist in your legacy product or dealing with the new ones you're creating as you write code this sprint.

Most of us should be familiar with bug triage and assigning severity and priority to bugs. All well and good but that doesn't get the bugs fixed and regression tested. I recommend an approach to assist with first managing the current load of existing bugs and to deal with any new bugs found.

1. If you aren't holding a weekly bug triage do this now. I've been on teams that didn't emphasize triage of bugs. It came back to bite them. As a scrum master on these teams my job is to facilitate and schedule these weekly triage meetings which is the first thing I did when encountering this issue. Second, make sure that you show up prepared with a query that can identify open high priority bugs, bugs awaiting triage bugs fixed but not verified, and all bugs that fail regression. This should give a quick look at the overall health of your product wrt bugs.
2. Now that you've got a regularly occurring bug triage meeting let's account for the time it takes to fix legacy bugs. On my past teams we've taken on the highest priority bugs during the sprint planning meeting by having a story for fixing the 'X' highest priority bugs. Note: this is an estimate, you will not be able to fix all of the bugs in the bug database. This bug "bucket" allows the team to carve out enough time for the highest priority bugs while still leaving time for the team to focus on features.
3. Developers are writing code during the current sprint, bugs are being created too. Your development team shouldn't be using the entire sprint to develop code, there has to be time to do testing and find/fix bug loop. If the team doesn't leave time to do this you will either ship low quality code and/or push technical debt into a future sprint. Which isn't good because the Product Owner is expecting the team to be ready to start the next set of features in the next sprint, not fix the left over issues from the last sprint.

Your mileage may vary but I've been relatively successful in keeping technical debt low, shipping high quality features, and meeting the needs of my team and customers using this technique.