Time for a bug bash.
What's a bug bash? Well, it's pretty simple. We the team - and it's always the team, not a person - have a lot of bugs to get through. And nothing major is wrong; there's just a lot of little cleanup work to be done. So we're all going to put aside that major feature we're working on, or that background task we're doing, and we're all of us going to work on bugs.
Forget, just for a moment, your defect tracking system. Forget your task list. Forget your backlog.
Grab a bug, and fix it. Repeat.
This is a timeboxed activity. You're going to have a two hour bug bash, or a one day bug bash, no more than that. And you won't sort, you won't think, you won't categorize. Pick up a bug, do your thing (fix, verify, whatever), and put it down.
That's a bug bash.
To do this, you'll need:
- a runner. This is the person filling your backlog, usually a project manager or other admin type. This is the person with a pool of bugs. You stick your hand up for another one, and the runner hands you the next thing. Any prioritization is done by the runner, and is entirely outside the concern of the team working on the issues.
- your team. No matter how much people are working on, everyone gets to work on the bug bash. You guys are the ones doing the work. No guessing on priority, no choosing areas that are good to work on, no guessing whether this really is important. Just take what you're given and fix it.
It helps if you order in lunch, too. Being together - preferably in one room - is important. It keeps you honest: no one can slip off for a meeting, or go grab lunch, or just do "one little thing" on a feature. You're all together, and you're doing bugs. It helps, too, if you don't look at the defect tracking system summary page. Just ask for a number and look at that bug only. It's less distracting that way.
Technically this can apply to any discrete task, but it works really well for bugs, since they tend to accumulate.