How do you handle bugs? There are many ways organizations handle bugs in software. I have what I think is a very workable approach, see if you agree.

The environment: The team is a dozen software developers and testers (total) and the project is run as a Scrum project. Iterations are 3 weeks.

Scenario 1:
QA is testing the build, and there is a bug discovered. The date/time field data that's entered in local time is stored in UTC, but the data comes back as UTC (not local) when retrieved.

1. QA logs a bug. Priority 2 Severity 2
2. Bug is assigned to the Product Owner for the team.
3. PO looks at the bug, and makes the call that the currently signed-off stories are more important than this bug.
4. The bug is estimated in story points by the team as 2 points.
   
5. The bug is put on the product backlog, prioritized along with the other bugs and stories.
6. The team can't "ship" the sprint's release with this bug outstanding, but the PO knows that they aren't planning a release for another two sprints anyway.

Scenario 2:
QA is testing the build and discovers that if a name is entered that is longer than 50 characters, the site crashes with an unhandled exception.

1. QA logs a bug, Priority 1 Severity 1
2. Bug is assigned to the Product Owner for the team.
3. PO knows that this bug is serious enough to warrant being fixed right away.
4. PO meets with the team, and the bug is estimated at 5 story points.
5. The team's velocity last sprint was 80, and they have committed to 78 points for this sprint. The team left only 2 points "spare" and didn't allocate time for bug fixes.
   
6. PO suggests that the bug be fixed this sprint, but the team does not feel they will have time enough to do that along with the other stories.
7. PO removes the lowest priority story from the sprint backlog, and replaces it with the bug instead.
8. The story goes back on the product backlog as the top story in priority.

There are also other permutations that may work in different organizations:

1. Abort the sprint, and replan a new sprint including the bug fix.
2. Allocate some time and time-box it just like a spike. The team may not be interested in working overtime, but try to negotiate it anyway. Most teams will want to fix bugs like this even if it means they work a few extra hours. Buy pizza.

The current team I am on doesn't follow these guidelines, and they insist that every single bug be fixed for every sprint, or the story can't be accepted as done. While I think this is a lofty goal, in my experience it just isn't practical. Maybe it's my old school days at Microsoft where "done" meant it was "code complete" but not "bug free." I think that Scrum gives us the ability to continue the current sprint and continue to develop the features as committed, and delay bug fixes until the next sprint. The only time when this doesn't work is the case where this sprint's story delivery is scheduled to be the release. And even in that case, most organizations allow a small window for last-minute fixes which could be used to take care of the bug.

If the developers are doing TDD, they won't be writing bugs in the first place... I see more than a handful of bugs per sprint at a clear process smell. In that case, the process should be evaluated to see why the bugs are being created in the first place. Is it unclear story descriptions? or more likely, is it a lack of testing in the functional, integration, and acceptance areas? Any way it goes, bugs seem to be a symptom, not the actual problem. Every bug I have written myself was due to a lack of a test for that area. Find a bug, write a test! Please make sure that your developers realize that when they estimate fixing bugs, that it should always include writing tests that first fail when the bug is present, then pass when the bug is corrected. Bugs should not be able to be resolved without at least a unit test to illustrate that they are really fixed.

Handling bugs can complicate a project manager's life, so if they are cropping up, be sure to address the root cause, and all will be happier.