3 ms·
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.
by stubish 8y ago
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).
- tonyedgecombe 8y agoOr just have a zero tolerance for bugs.
- gok 8y agoThat's effectively having a zero tolerance for functionality too.
- tonyedgecombe 8y agoNo it isn’t, in fact you could argue a better quality code base supports faster development.
- gok 8y agoYou have some examples of bug-free software that does useful work?
- tonyedgecombe 8y agoThat's not what I was suggesting and I think you know that.
- gok 8y agoWhat are you suggesting? I truly don't know what "zero tolerance for bugs" could mean.
- stubish 8y agoI don't know if you mean fixing every bug, or not creating bugs in the first place, but either way it is just the case where the teams bug fixing velocity is greater or equal to the rate of incoming bugs.
- e28eta 8y agoI first saw the suggestion at https://www.joelonsoftware.com/2012/07/09/software-inventory/ https://www.joelonsoftware.com/2012/07/09/software-inventory... 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.