James Shore has written about a crazy idea: Get rid of your bug database. He's not advocating that teams ignore problems - exactly the opposite, in fact.
Bug databases are often a black hole of to-dos, packed with hundreds of questions, feature requests, and genuine defects. Who has the time or energy to slog through that mess? Shore thinks there's a better way, though not everyone agrees - there was some vigorous discussion on this issue on the C2 wiki this summer.
Perhaps it depends on what exactly that bug database is being used for. Some of the reasons (good or bad) to use a bug database, mentioned by developers on C2, include:
- bugs reported by nontechnical people at times where there are no coders around
- Intermittent bugs
- bugs reported by multiple product owners and testing sites
- capturing a discussion about an alleged bug (e.g. it's a technology limitation)
- bugs which are integration-related and cannot be expressed by a unit test
- to allow customers, developers, manufacturing, QA, the field, marketing, et cetera to all share the same information
- Sarbanes-Oxley compliance
- development metrics over time
- "not only bug descriptions, but detailed reproduction steps, screenshots, crashdump data, movies, logs, callstacks, even references to code"
Shore acknowledges "Some bugs are too big to identify and fix immediately, and others are feature requests in disguise. For these bugs, XP teams already have a way to prioritize and schedule work: stories." Still, Shore proposes A Better Way to Fix Bugs (when you find a bug, fix it), A Better Way to Track Requests, and looks at How Can This Possibly Work? Essentially, he proposes replacing the vicious cycle of the ever-growing bug list, hidden out-of-sight in a database, with a "virtuous cycle" that decreases the number of defects as team members actively take ownership of bugs in real time.
He notes that a team may, in fact, need to use a dedicated bug database - but then they need some mechanism for getting stories out of the bug database and into the release plan. He notes that when XP teams let bugs pile up, their prime metric, velocity, is falsified and release dates can be put at risk.This "No Bug Database" article is part of a pre-publication review copy of Shore's in-progress book, The Art of Agile Development. He's looking for comments, saying "As you review, remember that our aim is to make an intensely practical book that shows mainstream development teams how to adopt and use agile software development."