Bug reports have priorities

Often the priority is relative to the team member who reported the bug. The closer the issue to them, the more important they consider the bug. Interns might consider the inability to set logos as a blocker.

That, however, is not realistic. Priorities need to be set relative to the business and not any individual. Development time needs to be allocated based on what is most important for the company.

Collecting money is most important, so base bug priorities on that

This way, it is clear to everyone what is important.

We set the following levels:

• Blocker level means that most money cannot be collected at the moment. It requires an immediate response, typically within an hour, and a resolution time quicker than four hours. Some examples are the payment processor being down, an error in the cart that prevents users from checking out, or the site being down entirely. It’s important to stress, however, that the cause is less important than the effect of not being able to collect money.
• Critical level means that not all money can be collected. It requires a response time of about two hours and resolution within eight hours. Order processing is partially affected, or a workaround exists, or critical functionality is significantly affected Depending on the number of users affected, this might evolve into a Blocker level. For example, users might temporarily be unable to pay with a specific payment provider, but you might have an alternative. Similarly, it might also mean that admin functionality that facilitates upselling isn’t working. Another example might be that suppliers might not be able to mark orders as shipped.
• Major level means that key functionality for a department is significantly impacted The expected resolution time is one working day. An example might be the admins not being able to filter orders. Or if the admin cannot bulk upload products.
• Minor level is a quality of life improvement or feedback for a non-critical feature that users have mentioned at least three times over the past two weeks. The expected resolution time is within the following development cycle, typically a week. A minor level report that generates daily user complaints should be considered major.
• Trivial A superficial error that users have noticed but did not have a meaningful impact yet. There is no fixed resolution time, but you should add it to the backlog. It’s to be upgraded to the minor level when reported sufficiently frequently.

Note that the frequency and timeline mentioned above are from our experience. They’re a good starting point. As you progress, however, you should adjust the numbers to suit your business.

After you’ve set the levels, educate the entire team and make sure that they consistently use the correct levels.

Because it directly relates to the business performance

Therefore, it makes everyone think of what’s important.

We also found it helpful that it doesn’t focus on the cause because it isn’t relevant.

It also makes the devs’ life easier because they have correctly prioritized reports.

The “three times” aspect is also valuable because it teaches people to listen to customers but not blindly follow what they say.

The challenge is in educating

Setting a standard isn’t particularly difficult. What is trickier is making sure everyone is aware of it and sticks to it.