For example, I generally prefer to work on small teams in an agile manner. This makes certain options more realistic than when working on a big, process-heavy team.

Below I list how I prefer to meet these goals, *when possible*. Basically I encourage rigorous, test-centric and feedback-centric development practices to discover bugs early, and discipline and team commitment to fixing bugs immediately when they are discovered. If testers and developers are integrated on one team, the lifespan of a bug after being discovered is extremely short, and bugs rarely make it into production, then a bug tracker becomes less necessary.

1.) Find problem areas in an application: keep the bug count extremely low. When more than one or two bugs is discovered in an application area, it can be identified easily without bug tracking software.

2.) Determine the severity of your bugs: Again, by focusing on keeping bug count low (by identifying and squashing bugs early), this becomes easy without a bug tracker. Serious bugs are rare enough that they are memorable.

3.) See who is causing the bugs: With the close collaboration that is expected on an agile team, this becomes obvious quickly.

4.) See who is fixing the bugs: Again, on a small, agile team, this becomes obvious quickly.

5.) Get an indication of testing quality: Agile teams often have a strong focus on early and constant testing. If *any* bugs slip into production, it’s a testing issue. They are few enough that a bug tracker shouldn’t be necessary.

6.) Help resolve feature creep: I like your idea here very much, and I would encourage many teams to use it. I prefer to use a slight variant, in that we keep a feature backlog, which we occasionally insert bugs that need fixing into (rather than a bug list that we occasionally insert feature requests into).

7.) Debriefing: Measure development team progress across projects: I actually think metrics can be misleading here. The important thing isn’t how many bugs made it into production, but how much these bugs affected the business’s reputation and bottom line. If your bug count is low enough, you can discuss each specific instance individually rather than talking about the total bug count for each severity rating in your bug tracker.

8.) Make the customer happy: When a customer points out a bug/flaw, it should be fixed immediately, rather than going into a bug tracker. This is not always possible, so a bug tracker or some other task list is often necessary.

As I mentioned above, these methods are much easier to apply in certain environments than others. I am not proposing to do away with bug trackers, but I will contest that they are not always the *best* way to meet your goals.

The spirit of the article was to show that bug tracking is more than a to-do list. I think there can be benefit to having the data for review in an any environment even if you don’t NEED it (such as above). Documenting bugs is too quick to call it heavy Plus, given the agile style of development, less bugs would qualify as appropriate to enter into the system.

My question is this:
The points you made rely on an experienced team of competent developers. What happens when they aren’t at that point? Do you use some sort of mentoring system, an experienced agile manager, or some form of both?

I bring this up, as it’s just another useful thing to get out of tracking your bugs.

The program was a great success, by the way. It allowed coders to measure their own progress as well as immediately demonstrate improvement in their own mastery of coding and the tools being used.