In most companies and projects, limited resources mean that as the ship date for a release approaches, only bugs with Priority 1 and 2 get fixed; the others are closed or deferred. Over time this practice leads to priority inflation. Someone entering a bug knows that this bug won't stop the product, but she remembers that none of her Priority 3 bugs got fixed last time and she really wants this one fixed, so she makes it a Priority 2. In the extreme, by a process of induction, all bugs become Priority 1 bugs and the purpose of the field is lost.
There's not much you can do about this except be aware of it happening and remind people what the priority fields are actually for.
Wednesday, July 18, 2007
Priority Inflation
Subscribe to:
Post Comments (Atom)
Posts
1 comment:
How about implementing a fair bug fix scheduler, which assigns bugs (as well as feature requests) to developers in a way that even bugs with low priority get fixed, like it's done in process scheduling in operating systems. While it could solve the problem you descibe, I really think this would not be accepted by developers as they really get degraded to slaves (do that, do that).
Post a Comment