How to prioritize backlogs efficiently

Developers love finding solutions to problems that can be solved with code. As a developer, I can vouch it is an amazing feeling when something you coded just works.
What devs really don’t like, it’s when there are bugs that need to be squashed.

That is because debugging is not as fun as writing code. As simple as that: debugging tools are awkward to use and most times error messages are cryptic.
Fixing issues requires a lot of Googling. (Stackoverflow is your best friend).

When you’re leading product, as a PM or so, bugs need to be addressed before they start piling up. Otherwise you’ll feel like drowning in them.
Prioritizing which ones need to be dealt with first, is a combination of know-how (practice) and strategy (can be learned).

The process

Within most companies, bugs are reported through various channels. Capturing them is the easy part when you have a defined process.
Internally and externally, stakeholders communicate with their teams and bugs are escalated until they hit a manager.
The manager has to prioritize these. But…how to do it right?

A fragmented process

Things become complicated because there are a lot of parties involved:

  • Customers: Are frustrated that a bug can be acute and disrupt their day or might be simple and just an annoyance
  • Support: Have to deal with customers frustration and get as many details as possible to pass on to the Testers team
  • PM and Engineering Managers: Have to assess the severity of the bugs, coordinate their resolution
  • Testers: Have to understand how a bug appears and how it can be reproduced
  • Engineers: Need to research, implement and test a working solution

Because of all these moving parts thus, bad communication and a bad prioritization strategy can lead to a lot of work for little benefits.

This can lead to frustration within the organization.

A better process

While communication can be improved within your company with a structured approach of meetings and deliverables, the process for prioritizing work is pretty standard.
A better process requires setting coordinates on the map: Severity and Priority.

Severity is the impact of the bug on the software.
Priority is the order in which a bug should be fixed.

Bugs that have the highest priority need to be fixed first.
As a rule of thumb priority beats severity, always.

First and foremost, understand the value of fixing a bug to the business: how is this going to affect the business. Is this going to impact revenue and customer’s experience?

Second, understand the value and consequences of fixing a bug: how many people and how much has it has impacted the usage of the platform.

Third, you need to assess the severity: complexity, time needed to deploy, required efforts.

Value + Consequence/Effort + Severity: This gives you the priority of fixing a bug.

Example:

You work in a bank.
The newest released API returns a different data-structure when calling the endpoint.
This creates an undefined variable and prevents users from logging in into your e-banking portal.
Value = 10
Consequence/Effort = 10
Severity = 1
Total = 21
Indeed, a simple fix & release that has a huge impact on the business

Priority should be assessed by a team of PMs and EMs leveraging all the data points you can from various parts of the business (customer support, QA etc).

Using this process you achieve the understanding of what needs to be done, extremely important in the world of software engineering.
A clear understanding of what needs to be done based on a “logic” assessment.

Parting thoughts

Here are some obvious and less obvious realities of prioritizing backlogs efficiently:

  • Deal with bugs fast. The faster you can squash a bug and release the fix in production the faster you will diminish the “pain” of having to deal with the whole bug fixing process. No one enjoys dealing with a bug for weeks as it causes intra-team struggles and adversities.

  • Having a short backlog means you have to prioritize less. Consider having a short one!

  • Dedicating a day of the week solely to the less fun parts of coding can be a great solution. Bug squashing together, pari-programming, code-reviewing as a team will help optimize these internal delivery processes. Often exercises that promote refactoring and code-reviewing are highly beneficial for the team’s cohesion and mood.

Cheers to you and to many successful bug-squashing days ahead!