A question that comes up from teams who are starting to get their feet wet scrum is, “What do we do with the bugs that come in during the sprint?”
Understand How Much Time You Are Spending on Bugs vs Planned Work
Do you know how much of your capacity you are spending on bugs? Any bugs from existing software should not eat up more than 20% of the sprint’s capacity. I will take that statement a step further and say that “emergent work” shouldn’t take up more than 20% of a sprint’s capacity. If it does, its usually a smell of technical debt or a smell of an environment that cannot support shielding the team from change for the duration of a sprint. If this is the case, the team may be better suited to a kanban based workflow system until things calm down.
If the bug fixing takes up 20% or less, then carve out 20% of the sprint’s capacity for bug fixes. If you don’t know how much of your time is being taken up by bug fixes, you need to measure it and find out.
If you don’t have enough bugs and issues to take up your 20% time, then you can allocate that time toward building technical credit: refactoring, unit tests, incrementing the architecture, continuous integration, etc.