Integrating user pain parameters to Bugzilla?
written on Thursday, May 29, 2008
Stumbled upon an interesting article on lostgarden.com about bug triaging. The idea is to rate bugs using 3 factors:
Type (What type of bug is this?)These factors are multiplied together to produce the bug "user pain". You can then sort your bugs using this single value. Sorting bugs this way helps focusing on fixing important bugs first.Priority (How will those affected feel about the bug?)
- 7: Crash: Bug causes crash or data loss. Asserts in the Debug release.
- 6: Major usability: Impairs usability in key scenarios.
- 5: Minor usability: Impairs usability in secondary scenarios.
- 4: Balancing: Enables degenerate usage strategies that harm the experience.
- 3: Visual and Sound Polish: Aesthetic issues
- 2: Localization:
- 1: Documentation: A documentation issue
Likelihood (Who will be affected by this bug)
- 5: Blocking further progress on the daily build.
- 4: A User would return the product. Cannot RTM. The Team would hold the release for this bug.
- 3: A User would likely not purchase the product. Will show up in review. Clearly a noticeable issue.
- 2: A Pain – users won’t like this once they notice it. A moderate number of users won’t buy.
- 1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect sales.
- 5: Will affect all users.
- 4: Will affect most users.
- 3: Will affect average number of users.
- 2: Will only affect a few users.
- 1: Will affect almost no one.
Read the article for more details on the way it should be implemented (in particular why the factor values are qualified, rather than simple values).
For a few days, I started sorting my own bugs this way and I like it.
It would be a great addition to our Bugzilla server, in my opinion (note: this does not mean I volunteer to add it myself :-)). What do you think about it?