If you are in a buggy group, you have a lot of bugs.

After writing the preceding, I’ll endeavor to make the rest of this post slightly less obvious.

Anyway, so, you have a lot of bugs, and you need to get better. How can you get started?

Well, there’s a common technique in agile called root-cause analysis. It’s a good technique, but your team isn’t ready for it and you can’t afford to do it.

Instead, I recommend a technique I came up (probably not uniquely) that I call “bug categorization”. I started this when I team that I was on had a notably buggy iteration, and I noticed that a fair number of the bugs were just sloppy – not reading the spec, not running the app after they had made a change, that sort of thing.

What I wanted was a way to help the team to clean up their act without being prescriptive.

So, I went through all the bugs – something like 120 – and did a really quick classification on each of them, putting them into one of the following categories:

• Foreseeable: This is a bug that we should have caught.
• External: Somebody else broke us.
• Existing: This bug existed in past versions of our software.
• Spec: There was a problem with the spec.
• Other: Something else.

At our retrospective, I presented a graph of the bugs, and then put up a post-it that said, “too many bugs”.

And then I let the team work on the problem. And they did great, cutting the foreseeable bugs significantly in just a few iterations despite me expanding the definition of foreseeable to include more bugs.

And while my initial impetus was to reduce the sloppy bugs, the team spent a lot of time fixing bugs related to definition and communication. For example, they invented a dev/test/pm meeting that the start of a story to make sure everybody was on the same page.

So, that’s bug categorization.