Krdytkyu

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.

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!

This really boils down to what you consider to be more important. The P2 bug or the new feature?

Usually an agile project management system will include some sort of prioritisation meeting where tasks are ordered by priority and worked on in that order.

Developers are not allowed to choose the tasks they work on. That's the job of the project manager. Who must ensure that the project has the largest number possible of important features included before the budget runs out.

That's really the most important thing. Simple rules like "fix at least 1 P2 a week" don't really help this goal.

It is a pretty common cycle for a software to pile up noncritical bugs until something gives, then a big event happens and many of them are fixed at a time; maybe by dedicating a sprint or two to only bugfixes before a big new release, or by the software being EOL and having survived the heap-o-bugs.

So you're in good company if your devs just let them slide. Of course you can juggle around with "rules" like you mentioned ("if you're not working on a new feature, you must work on at least one P2 per week"), but that will likely just make you unpopular.

My question is how to have people deal with bugs, without imposing a strict agenda and yet to have it resolved.

Instead, I would suggest to change the overall mindset a bit, and make bugs more like features in the sense that they are first class citizens in your backlog. Yes, new features are great; yes, management and sales pull very hard on new features. But having a stable, well-functioning application instead of a huge pile of messy bugs is also important.

Don't tell your devs that they must do work they don't like; but try to change the athmosphere so they like working on bugs. Try to instill a sense of pride in a bug-free application. Make it more fun (sic) to work on a bug by specifically allowing them to actually fix the underlying reason which made that bug manifest (i.e., not just quick workarounds/hacks), if there is any. Ripping out some broken class structure and replacing it with something more suited can be very entertaining for devs. If you have some broken central piece which regularly makes bugs manifest elsewhere, fix the central piece.

How you reach your goal is highly dependent on your own character and that of your teams - don't try to fool them into what you want to achieve, but have open discussions, try to get a peer effect running, let them come up with a working process themselves, and so on.