How to Prioritize Bugs ๐Ÿ›

A few strategies to move fast, reduce conflicts and keep your backlog small.

Bug fixing is not exactly everyone's favourite engineering activity.

It's a tricky process that requires coordination between several stakeholders, and it's not easy to get it right.

Think about it for a moment. Bugs might be reported by Users to Customer Support, reproduced by QAs / Testers, looked into by PMs and eventually addressed by Engineers.

It's a lot of people involved.

Now, every team has a slightly different process for this, but it always involves some version of these steps:

  1. โœ๏ธ Report โ€” bugs are entered in some kind of backlog (...or notified to devs on Slack ๐Ÿฅฒ)

  2. ๐Ÿšฅ Prioritize โ€” bugs are triaged and a priority is assigned. This might be done by QA, PM or Engineers themselves.

  3. ๐Ÿ”จ Fix โ€” bugs are addressed and fixed by Engineers.

Out of these three, I have seen the most problems happen in the prioritization stage. Who takes such decisions? How do we avoid conflicts? How much time should we spend on it?

Let's figure this out ๐Ÿ‘‡

๐Ÿ‘ฅ Stakeholders

When it comes to the importance of fixing this or that, every person involved in the process has their own opinion.

  • ๐Ÿ… Customer Support knows about users who need the fix, and what workarounds they have put in place.

  • ๐ŸŽจ PM knows how bad this is for users and business in general.

  • ๐Ÿ” QA knows how badly broken the feature is.

  • ๐Ÿ”จ Engineering knows how bad this is for software.

Every point of view is legitimate and complementary, because no one sees the full picture.

Without a clear process that turns such opinions into actions, you might:

  • Spend too much time on negotiation โ€” there is only so much time you can spend on deciding what do sooner or later, before it becomes more valuable to use that time for fixing bugs in any order instead.

  • Have people/roles feel underrepresented โ€” if process is unclear, priorities end up being defined by people with the loudest opinion or the most social capital.

  • Work on the wrong things โ€” you address issues in the wrong order and reduce the value you could bring.

๐ŸŽฏ Goals

With that in mind, a good process for bug fixing should achieve two goals:

  • Get basic priorities right โ€” in a "good enough" fashion, being inclusive with people but without wasting anyone's time.

  • Ship things fast โ€” so that the order in which things are fixed matters less.

How to achieve these goals? Here are a few strategies ๐Ÿ‘‡

๐Ÿ” Separate severity from priority

A good way to involve all stakeholders in prioritization, while also keeping conflicts low, is to consider two separate values of importance for a bug: priority and severity.


Priority is how bad this is for business. How much revenues are we losing? How bad is the experience for customers?

Priority should be assessed by the PM, with the help of Customer Support in case of user-reported defects.

In many articles you find priority defined as how quickly you should fix this. I never really liked this definition as the โ€œquicklyโ€ part seems to me more of a consequence of the business value.

If you lose track the original meaning and only focus on the "how quickly", you get a recursive definition that is not very helpful.


Severity is how badly broken the feature and software are. Is this feature still usable? Why is this happening?

Severity is assessed by QA and Engineers, who can ignore how relevant the broken feature is, to focus on how much it is individually impacted by the bug.

Engineers can also evaluate whether the issue is symptom of a larger disease, and things are more broken under the hood than it seems.


Once you have set severity and priority values, you can simply fix bugs in this order:

  1. High Priority + High Severity โ€” e.g. the login is broken and users can't access the tool.

  2. High Priority + Low Severity โ€” e.g. terms & conditions are not visible anymore before users make the payment.

  3. Low Priority + High Severity โ€” e.g. the checkout doesn't work with some niche combination of device + browser.

  4. Low Priority + Low Severity โ€” e.g. border radius of the button doesn't match the design system.

Basically, priority wins over severity, with the latter being considered when the former is equal.

This framework is powerful for two reasons:

  • Separation of concerns: it avoids the negotiation between the business and technical side of the team, because each side gives its own value separately.

  • Clear sorting: It provides a clear rule for deciding in which order to fix bugs โ€” one that doesn't need to be rediscussed every time.

๐Ÿ“‹ Keep your backlog small

Does the process above create the perfect sorting? No. But it should be good enough as long as you are fast at fixing bugs.

The faster you are at fixing, the less important the order is.

How do you understand if you are fast enough? A simple KPI is that the backlog is slim and it doesn't grow. It's really important that both these conditions are met. In fact:

  • If the backlog is small but it grows week over week, you are going to have a bad time in the long run.

  • If the backlog is big but it doesn't grow anymore, it might simply mean people lost faith in your bug fixing, and stopped reporting new issues.

As a rule of thumb, consider the backlog as a bad thing โ€” and try to keep it as small as possible. Long backlogs destroy the feeling of progress and demotivate everyone in the team.

If, despite your efforts, your backlog becomes too big, consider declaring bankruptcy and burn all items older than a few months. It might seem daunting, but important issues always resurface at some point, so you don't really risk to lose anything critical.

โฑ๏ธ Spend fixed time on maintenance

Spending adequate time on bug fixing is often challenging and subject to negotiation.

One approach that keeps things simple, while also limiting conflicts, is to allocate for it a fixed amount of time every week.

This time shouldn't be spent only bugs โ€” it could include general refactoring, library updates, and other small changes.

The right share of time depends on your team and your product, but I have seen many having success with something between 20 and 30%.

We have used this approach for many years, and I have written more about it in a previous article.

๐Ÿ“š Resources

To learn more about bugs, priorities and backlog, here are a few great articles:

And that's it for this week! How do you prioritize bugs? Are you happy with your process? Let me know in the comments ๐Ÿ‘‡ or via email ๐Ÿ“ฎ

Hey, I am Luca ๐Ÿ‘‹ thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Friday and put your own growth on autopilot!