Having a prioritised backlog helps to have a solid roadmap for the product. It’s like gardening. Care and grooming is necessary. We will discuss some of the best strategies here.

Ensure that the bugs, change requests, and enhancements requests are logged in to a system. Jira is very useful. It’s Ok to keep it in something simple as an Excel sheet – but always make an entry of it. I am referring all of them bugs in this post.

Analyse from where they are coming. That will help you to bucket them and prioritise easily.

Dev team – for example, clearing of a technical debt. Suppose, you use an outdated API, you may need to upgrade it. MacOS releases a major update every year – an outdated API can give performance issues; this could be applicable for iOS / Android platforms also. You could specifically have dedicated sprint for this.

Bugs from pre-release – Pre-release users do a great job in testing the product, before its release. Most of these bugs can be prioritised during the feature development itself. In doubt, wait for the product release and see the real user reaction. Then take a decision.

Quality Engineers bugs- QEs test the product – mostly new feature. Prioritise this during the feature development itself. Feature development can be considered complete only after these issues are fixed.

Customer Support – Customer Support executives know customer pain points. These bug come after the product release. The severity of the bugs can be easily determined based on the customer call volumes. Prioritise for the very next product version release.

Bugs from user forums – Again, number of comments and votes helps in prioritisation.

It makes a lot sense to attach a priority for each bug. Internal QE team generally are trained to get the priority correctly. For rest of the sources, review the bugs and get the priority correctly. It will help you to assign the bug to each release that are coming up and then filter to create meaningful dash boards.