Jim'sPages => StoryProcess => DefectStories
The PlanningGame page suggests creating stories for defects and feeding them into the regular iteration planning process. Most AgileMethodologies are not real firm on this, and offer other choices. Some alternatives:
If you value quality above all else, you might as well work on defects FIRST rather than let them pile up. If there are few defects, there will be a few in every iteration. What distinguishes this approach is that if you have lots of defects, there may be an iteration or two now and then that deliver nothing but bug fixes. This sounds a bit like Bigfoot ... I have heard in legend that there are teams out there that do this, maybe there is a grainy photo or two, but I have never seen one in captivity.
This approach devotes a handful of developers to fixing bugs. Defects get a consistent resource load that can be more or less ignored when planning other stories. The rest of the team goes to the planning game while these few work away on the defects.
This one bothers me because it makes some implicit assumptions about priority. Say the Tiger Team is working on a defect and the rest of the team is working on a feature. Because they are in the same iteration, they are receiving the same priority. But what if the main team is winding down to the low priority stories while the Tiger Team still has several major defects in queue? Or the main team is sweating a mission-critical above-the-value-line feature and the Tiger Team is correcting the spelling of a button?
Now the obvious solution is to change the resource allocation. Move people between the two teams until the resources match the priority. But that takes you directly to...
Of course I saved the best (my choice) for last. Make an index card for a defect just like any other story, and let it sink or swim in the planning game. The customer can give a very precise priority to each defect. The planning game should put all remaining stories - or at least the next couple iterations worth - into literal implementation sequence. Defects can be prioritized by all the same criteria including business value to the user.
I worked on one team that has several defect categories. Show Stopper means we cannot release the product. Low means fix it if you get the chance, but don't sweat it. I'm not sure what High means. Is it below the line of value - we can ship without the fix - but more important than some of the stories above the line? I think it means we'd like it fixed, but not at the expense of certain other stories. The clearest way to express that sentiment is the planning game. Put the defect card in the sequence right where it belongs.