We have a bug process that is currently being worked.
We have 3 levels of bug:
- P1 bug: Bugs that prevents users from working. They must be solved on the spot.
- P2 bug: Bugs that are impacting but users can work
- P3 bug: Bugs that are not impacting and where users can work.
P1 is mandatory and must be dealt on the spot. But for for P2 and P3, we judge on a case by case basis.
With the 3 levels that we have, the team has the tendancy to work on more pressing new developments asked by the customers, instead of dealing with P2 and P3, which is almost like non urgent.
Questions are the following:
Should I add another level of priority, like having a P4?
Should I also assign them targets for dealing with non urgent tickets like in this week, when not assign a coding task, you should treat at least 1 P2?
Currently, we do not have objectives like I raised above but my concern is that giving them such objectives can be brutal. The thing that is certain is I need to talk to them about the objectives, the team like to be involved in discussion especially when we are setting objectives.
Update:
I was proposed this question in term of similarity. However it is not similar, at all.
My question is how to have people deal with bugs, without imposing a strict agenda and yet to have it resolved. So no, the question implied does not help me. Still, thank you.
Best Answer
Generally you have two axes for bugs: gravity and frequency.
So obviously something grave and frequent is of the highest priority. However, something that's serious but happens rarely should be weighed roughly at the same as something that's not serious but happens often. So supposing you rate gravity from 1 to 3 and frequency from 1 to 3, the types of bugs you should probably be fixing are those which cross the diagonal defined by gravity 1, frequency 3, and gravity 3, frequency 1.
A blocking error or an error which could create potential damage to client information would always be a gravity 3. Similarly, an error with gravity 1 is not likely going to noticed by the user or has low priority. If you aren't sure here, 2 is probably a safe number to assign.
An error the user sees each and every time the program is launched is going to have a frequency of 3. An error with frequency 1 is going to be something which happens rarely if at all. Again, if you aren't sure, 2 is probably a safe number to assign.
It's mostly subjective on what constitutes a bug with gravity 3 or a bug with frequency 3, but use your common sense. A bug with gravity 1, frequency 2 is perhaps a misspelled label. A bug with gravity 2, frequency 1, might be proper error handling when database connection is down.
Again, this is just a rough idea, but the idea is to give emphasis on what should be the focus for bug fixing as a sort of triage. Clearly it is not possible to eliminate all bugs, blocking or otherwise, though at least with this methodology, you can safely say that bugs are not too pressing or too frequent. If you solely fixed bugs which are blocking errors, then the high frequency errors will be ignored and users will notice that you didn't fix these bugs.
Also, for convenience, you may find you prefer to provide letter grades for gravity or frequency, so you can say that a bug is a B3 error, and it is clear both the gravity and the frequency.
Good luck!