Bug lists have the potential to consume a lot of your organizations effort. Bugs drive re prioritization, dispatching, reporting, followup – even though they might be of one time nature and random occurrence. Whenever I encounter a huge bug list is to I ask which of these the organization will fix the upcoming release and then why they care about tracking the rest.
Over the years I have gotten a number of different answers to why the huge bug lists is maintained. I’ve found that many answers are really confusing the original purpose (to fix it) are with something else. An example can be mixing the purposes of “learning what provides a top notch service from the eyes of the customer” , “fixing the damn thing” and “tracability” – then attempting to provide answers to all of these above from the same tool.
I’ll share some of the dual purposes with you to provide you with some simple litmus tests. Each the well intended purpose below have better solutions.
- For keeping track of product limitations
- Awaiting and aligning prioritization (to be done later since organization units use different prioritization schemes)
- For reporting without action
- For maintaining traceability although we do not intend to fix it (ever)
- For dispatching to the right team
- For learning about frequent reoccurring sources of problems (this can be done outside the bug list)
- For pleasing every customer/user (some have marginal value)
- For maintaining pressure on the organization (political motives)
Hope it helps!
/mts
