When migrating an existing project to Scrum, you are often faced with a backlog of unfixed bugs from the pre-Scrum era. What's the best way of working down this backlog of bugs? Mike Cohn recommends assigning story points to these old bugs and prioritizing them in each sprint by using the normal Scrum workflow:
My usual recommendation is to assign points to the bug fixing. [...] We are able to see how much work the team is really able to accomplish but also able to look at the historical data and see how much went into the bug-fixing story each sprint. Knowing this can be helpful to a team and its product owner. For example, imagine a situation in which the product owner is considering suspending bug fixing for the next six sprints in order to add a valuable different feature into a release. If we know that the team's full historical average velocity was 25 but that 5 points went to bug fixing each sprint, we know that suspending bug fixing for the next six sprints will result in 30 (6*5) more points of new functionality.
In addition to sprint prioritization strategy recommended by Mike Cohn, Charles Bradley also wants more options for the development team to fix bugs within the sprint:
[...] while PO's are certainly allowed to prioritize bugs into sprints, the dev team is also allowed to pick any bug it feels needs fixing (whether it be on the backlog or not), and bring that into the sprint as a task (they gain no story/velocity points for this, regardless of whether the bug was on the backlog or not). Only the dev team can decide how much product backlog to bring into a sprint, so if they decide to spend ~ 50% of their sprint bug fixing things not prioritized by the PO, so be it, but it will be visible because their velocity will be lower.
Jack Milunsky makes an important distinction between how to handle legacy bugs versus bugs written within the current sprint:
The only time one should assign story points to bugs is for legacy bugs. There is definite value in this for Product Owners—specifically quality in this case. Bugs found and fixed during the sprint should not be assigned any story points as this will affect the velocity in such a way as to provide false sense of how fast the team is moving.
Should we assign story points to fixing a bug that was written under Scrum rules but has somehow escaped the boundaries of its sprint? That is, what about bugs found in user stories that were declared "done" in some previous sprint? Ron Jeffries writes:
If somehow a story slips out and then a defect is found, that story has already been recorded in velocity. Velocity is artificially high. What should we do? One possibility is to reduce our progress bar by that amount, and insert that story back when and if it is fixed. That might be more accurate but it is not necessary.All we do, instead, is count only the stories done next time. Time spent fixing the broken one does not count. Our progress line drops by one story, starting now. The line was artificially high for a while, but now it is back in line.
Note that the defect may take less time than it took to build the story wrong, or it may take more. Either way, the time necessary to complete the story correctly, and the number of stories completed, is back in balance with respect to that story. No estimation is required, no rationalizing about why we should treat what is obviously waste as if it were somehow a good thing.