13

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.

Andy K
  • 285
  • 3
  • 9
  • 1
    Possible duplicate of [How can I convince management to deal with technical debt?](https://softwareengineering.stackexchange.com/questions/43948/how-can-i-convince-management-to-deal-with-technical-debt) – gnat Dec 03 '18 at 09:42
  • 1
    usually priority level is not as useful as priority ordering... "bug X" is more important than "bug Y". if you add p4 eventually you'll want p5 and p3.5 – sudo rm -rf slash Dec 03 '18 at 15:16
  • 2
    If you have so many P1 bugs that all of your developers are always busy fixing them instead of working on P2/P3, you're doing something **very** wrong. Don't add any more features for a while. Focus on drilling down and fixing the architectural (or personnel) problems that are almost certainly causing many of these bugs. If you're coding in C++, for example, make sure you're using RAII everywhere you can, so you don't forget to manually `.release()`. – Nic Dec 03 '18 at 17:48
  • 1
    What is your goal? Do you want developers to work more on bug fixes and less on new features? Please edit your question to clarify. Also, please describe how developers currently receive or take on work? What is used to decide what gets worked on? – sleske Dec 04 '18 at 12:08
  • feature, bug, change whatever you call it, the software does not do what it needs to. The only difference between a bug and a feature is who pays for it. – mattnz Dec 05 '18 at 04:28

3 Answers3

30

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!

Neil
  • 22,670
  • 45
  • 76
  • 3
    In reality, there's only one metric for bugs - ROI - how much will it cost to fix compared to how much the company loses for not fixing it. Compare that to the features. Of course, how you calculate that metric involves the gravity, frequency, etc. – corsiKa Dec 03 '18 at 16:29
  • 3
    @corsiKa, yes ROI is a composite metric: "return" and "investment". And for bugs, return can be modeled as a composite of "gravity" and "frequency". – Paul Draper Dec 03 '18 at 17:51
  • @PaulDraper Ultimately, cost and return are measured in dollars. As a business with shareholders, it is the only unit of significant value. – corsiKa Dec 03 '18 at 19:36
  • 11
    @corsiKa, that sort of cold-blooded selfish analysis of quality decisions is actually *extremely* irresponsible. It's the same logic that leads to pharmaceutical companies circumventing efficacy testing laws if they can "get away with it," or keeping profitable drugs on the market despite the severity and frequency of adverse effects. It's the same irresonsibility that leads to vast botnets composed of insecure consumer routers and "smart" devices, because the manufacturer couldn't see any dollar value in good security. Gravity and frequency are MUCH better metrics than "bottom line impact." – Wildcard Dec 03 '18 at 20:34
  • 3
    @Wildcard I'm literally a communist, so I 100% agree with you that those are better. That doesn't change the fact that this is how software companies are run, and going against that tide, unless you run the company, will drown you. Although it's worth noting, it isn't selfish. It's single-serving, but that single isn't the self, it's the company. Just, throwing that out there. – corsiKa Dec 03 '18 at 20:52
  • 2
    @Wildcard and corsiKa the company is not a big one and we cannot afford to say "oh we are going to lose money, then let's do something otherwise let's keep it still". In the grand scheme of things, however, I do not believe that the approach you mentioned is sustainable in the long run. People - Customers are far from stupid. The companies who has been preaching that kind of gospel, Sun , to name one are no longer here. I've been working in account management long enough that money is not earnt that way. To anyone, if you happen to work for such company where the company lacks loyalty 1/n – Andy K Dec 03 '18 at 22:30
  • to its customers and if I were you, I would think hard if that company would lack loyalty towards me at one point... 2/n n=2 – Andy K Dec 03 '18 at 22:34
  • 1
    @corsiKa: I agree very much to your ROI statement. However, measuring the dollars is quite hard, especially the dollars a company looses because people don't buy the software. And frequent annoying bugs, even if their severity is not high, can lead to tons of bad ratings in the App store or some other rating platform, which can easily convince people to buy a competing product. So fixing bugs, even non-severe ones, is often a strategic decision, surely with the intention to maximize ROI, but in the long run. – Doc Brown Dec 04 '18 at 13:32
23

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.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • "what you consider to be more important. The P2 bug or the new feature?" This could be covered even more simply by assigning equivalent priorities to new feature tickets. e.g. a P2 new feature is more important than a P3 bug. But, of course, there has to be a process or person capable of deciding this. – Joe Stevens Dec 03 '18 at 15:12
  • 5
    The trouble with assigning priorities is that whatever bucket granularity you choose you always end up with more than one per bucket. You need to put things in order, not just say "all these are TOP PRIORITY!" – Ewan Dec 03 '18 at 15:15
  • 6
    @Ewan There is also the possibility of priority inflation where your highest bucket has more issues than you can ever hope to address, and new levels of priorities are invented outside of the bug tracking system. I have heard people speak of P minus 2 issues. – kasperd Dec 03 '18 at 15:26
  • 2
    Saying developers are not allowed to choose the tasks they work on will harm your productivity. If a developer is blocked on the highest priority issue they were working on, it's better if they can work on another issue in the meantime than them not doing anything while their first issue is blocked on something. Moreover issues which are not harming users but are harming developer productivity are often not prioritized as high as they should be. Finally telling developers they aren't allowed to make decisions of their own is a sure way to destroy motivation. – kasperd Dec 03 '18 at 15:32
  • 3
    @kasperd I think most developers accept that they are employees as well as technical super geniuses and accept that their employer gets to decide which tasks should be done first. Obviously if one is blocked you would move down to the next most important, but you dont skip 10 important tasks to work on the cool one. – Ewan Dec 03 '18 at 15:39
  • @Ewan That definitely depends on the size of the individual tasks. Ideally you work on a task that you can finish before you are unblocked on the first issue. – kasperd Dec 03 '18 at 16:00
  • 1
    I've found that if work is completed or blocked, instead of pulling another developmental task into the sprint (doing scrum) a bug should instead take priority. MS famously gave _all_ bugs the highest priority over any development tasks when working on Windows 2000 - they found that it was the best way to produce non-buggy software (one of the reasons that 2000 was actually well liked) as if they didn't, bugs would tend to get left as there was usually some new development to work on instead. – Baldrickk Dec 03 '18 at 17:00
1

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.

AnoE
  • 5,614
  • 1
  • 13
  • 17