| At an Agile presentation several years ago, they suggested the following approach: a) Bugs get broken down into manageable tasks of roughly the same size (eg. about 1 day to fix). b) You measure the average velocity that your team fixes these triaged bugs. c) When the number of bug reports exceeds the teams velocity, you know that number of bugs will never be fixed. d) Be brutal, and flag that number of the lowest priroty bugs that will never be fixed as WONTFIX. Now you have a manageable queue of bugs, say as many as your team can fix in two months. And the submitters know the score and know waiting isn't going to help. Lots of productivity and efficiency bonuses all around. But nobody does this or any of the similar variations, because people rather leave bugs that everyone knows will never be fixed in the system 'because they might be' or because they don't want to listen to the butt hurt submitters complain because they place a higher priority on fixing the bug than the people they are trying to convince to fix it. And yes, this approach might seriously piss customers off enough that it is a PR nightmare, so I'd be interested in anecdotes of this sort of approach being applied and how it worked out (even just internally). |
He makes a reasonable case that not keeping the bug queue manageable leads to increased cost. I've definitely been in bug triage mtgs where we spend more time discussing a bug than the code change would take.