Every product past a certain age has a bug backlog too large to read. Nobody planned it: bugs were reported, triaged as low priority, and left. The list grows monotonically because nothing removes items except fixing them, and the low-priority ones are never the most valuable work available. Eventually the backlog is a place where reports go to be forgotten, and the team knows it, which changes how they treat new reports.
The honest first step is to admit what the list is. A backlog nobody will ever work through is not a plan, it is a record of things you have decided not to do while pretending otherwise. Declaring bankruptcy on it — closing everything older than a stated age with a note that it can be reopened if it recurs — is uncomfortable and it is usually correct. Anything genuinely affecting users will be reported again within a month, and now it will be visible.
Then make triage a real decision with a small number of outcomes. Fix now, because it affects users materially. Fix in this cycle, scheduled with an owner. Will not fix, closed with a reason. And needs more information, with an expiry after which it closes. What kills backlogs is a fifth outcome — later — which is not a decision and is how the list grew in the first place.
Priority should be assigned by user impact rather than by technical severity or by who reported it. How many people hit this, how bad is it when they do, and is there a workaround. A crash affecting three users weekly matters less than a confusing error message affecting three thousand, however much the crash offends an engineer. Firms where priority tracks the seniority of the complainant end up fixing whatever the loudest customer noticed, which is not the same as fixing what matters.
Watch the flow rather than the total. Bugs opened per week against bugs closed per week tells you whether you are gaining or losing ground, and the age of the oldest unresolved item in each priority band tells you whether your triage is honest. A team whose closure rate matches its open rate has a stable situation regardless of the absolute number; a team where the total climbs every month has a trend that no cleanup sprint will change.
The uncomfortable finding this usually produces is about where the bugs come from. Track them by area, and a small number of components will account for a large share. That is not a testing problem, it is a design or quality problem in specific code, and the right response is to fix the component rather than to keep fixing its symptoms. Backlog data is the cheapest quality signal a team has, and almost nobody looks at it that way.
