Bug fixes and building new features are always in competition with each other, and it’s common for teams to have a hard time deciding where they should spend their time when it comes to prioritizing these two conflicting, but equally important tasks.
One major problem is that prioritizing errors isn’t always clear. Figuring out how much negative impact a bug is really causing is important to answer because not all bugs are worth fixing.
That’s why having a solid workflow in place for prioritizing bugs is so important. In order to confidently allocate your engineering resources on bug fixes and feature building, you need to understand the scope of each application error, and its impact on your customers. Then you can definitively say particular bugs are high enough priority that they should be scheduled into a sprint alongside your work on building new features.
Here’s a best practices guide for managing the prioritization of software bugs.
To get off on the right foot, be sure to invest some time in setting up a robust system for detecting errors and alerting your team. This will go a long way towards helping your team be proactive about bug fixes, and give them visibility into which errors cause the most harm. By thinking about your setup from the start, you’ll make it easier to prioritize the right bugs to fix down the road.
It’s quite common to hear of engineering teams who mostly find out about bugs and fix them when a customer complains. This is a negative experience for the customer, and for the ones who do complain, there are probably countless others who gave up and churned from your product.
Proactively detecting errors when they happen can solve this problem and provide a better experience for your users. You’ll also have insight into how widespread errors are, so instead of reacting to whatever appears to be the greatest pain based on complaints, you’ll actually be able to fix the most harmful errors.
When it comes to prioritization, a great place to start is by making your alerts smarter. Alert fatigue is something all engineering teams should be wary of, so instead of receiving a notification every time an error happens, opt to receive alerts for:
This way you can stay focused on errors you haven’t seen before, or ones that might have a greater impact on your customers.
You can increase visibility into the impact of each error by aggregating errors by root cause. A long list of error instances is better than nothing, but it really doesn’t offer much clarity into how frequently a given error is occurring, or how many users are being affected - key indicators into an error’s impact.
By grouping like-errors together, the ability to assess an error is much easier because you can see exactly how many times an error happened. This visibility gives you the information you need to prioritize bugs effectively.
Modern applications are made up of various systems, often built in different languages and using different technologies. Errors are not limited to manifesting within the borders of just one part of your app — a bug in your frontend code could be caused by a bug happening your backend code. If error information is spread through various systems, piecing it together can be a challenge.
By bringing all your error reporting together in one place, you’ll be able to track bugs throughout your system and understand how widespread they are.
Now that you’ve configured error reporting to work for you, some simple actions for cutting down noise will help keep things actionable and bring focus to your prioritization efforts.
There are some bugs you’ll never be able to fix, like bots spamming your application with nonsense form data and URLs. It’s a good idea to turn off notifications for this kind of activity by silencing these notifications. In Bugsnag, you can do this with the Ignore action and all future notifications for that error will be silenced.
There are also times when an error might be important to fix in the future if it becomes more prevalent, but until it reaches that level, you shouldn’t spend time thinking about it.
Rather than leaving those types of errors sitting in your inbox (which can take up mental space and detract focus from errors that need immediate attention) snooze notifications for them until they reach a critical threshold.
Once your system is setup and error noise reduced, proper workflow and strategies will help you prioritize the most relevant errors first.
One of the most important things to consider is how much of your user base is impacted by an error. Generally speaking, a bug that only affects one user is probably less of a priority than one which affects hundreds. Mapping errors to users, in combination with grouping errors by root cause, is essential to this. In Bugsnag, for example, we show you how many users were impacted by a bug, alongside the error frequency, and let you sort by these metrics, so you can immediately understand how widespread an error really is.
Another prioritization strategy is selecting, in advance, certain areas of your code you want to monitor more closely. For example, you might want to monitor and prioritize bugs in the checkout portion of your application, or on the signup page, more urgently. You can do this by passing in custom diagnostic data and then filtering to view all the errors impacting this area of your code.
Similar to focusing on key areas of your code, you can also watch for errors that impact your most valuable customers. You can pass in custom diagnostic data, like pricing plan, which will be attached to the error reports of all your customers. Then simply filter for customers on a specific plan level to view the errors they’ve experienced in your product.
Another way to make prioritization easier is to only view errors in the releases you’re most interested in, like your latest or maybe two latest releases. That way you can focus on fixing bugs in the newest versions of your application since many of your customers probably will have upgraded, making supporting older versions of your app less important.
Once you’ve identified the most important errors to fix, you’re not quite done yet. It’s important to then figure out what to do with them by getting them into your debugging process. Will you assign errors to your teammates directly from your application error monitoring tool, or will you create issues for them in your issue tracker? Be sure to have a debugging workflow in place to help you move forward with your prioritized errors and resolve them. Check out our collaborative debugging workflow guide for strategies to help you get started.
Using an application error monitoring tool, like Bugsnag, can give you visibility into your errors so you can prioritize them effectively. With best practices for getting setup and a streamlined prioritization workflow, you’ll save time and remove any guesswork from dealing with incoming application errors.
For help leveling up your team’s debugging workflow, check out our tips and suggestions in our collaborative debugging workflow guide.
Bugsnag automatically monitors your applications for harmful errors and alerts you to them, giving you visibility into the stability of your software. Take a proactive approach to code quality and fix errors impacting your users.