Does adding new features when existing features have bugs bother you?
Managing software projects used to feel like I was a car salesman throwing in a set of winter tires (sometimes in Arizona!) while neglecting a burned out headlight. It's not dishonest, but it's not the level of quality and service I want to produce.
Even as my perspective of business priorities matured, this feeling never changed. I just can't bring myself to excuse or minimize it.
A few years ago at the direction of the CTO, I had an opportunity to pursue bugs with extreme prejudice and the team eventually whittled our backlog bug count down to zero. It was awesome! It changed the way I thought about quality and since then I've been of the opinion that software projects have no excuse for any bugs in the backlog.
Achieving true bug-free code is very unlikely, but reaching a point of no known bugs is possible. Two of my teams have brought their shared backlog down from 2,000 bugs into the 50's* and I've had four other teams get down to zero and regularly return to zero at the end of each sprint. Again, this didn't mean our software was completely bug-free, but it did mean all reported bugs were quickly resolved.
This did a few things for us. First, it felt good knowing we had cleaned house and customers were no longer experiencing those issues. Second, it sent a signal to everyone that this team cares about quality. We want what's already been built to be as good and perfect as the new stuff we're building. It also gave us a clear picture on the state of the product quality because our backlog accurately reflected it. And lastly, it made triaging more meaningful because we could honestly evaluate incoming issues without ignoring old bugs that may or may not be more important.
*Among other things, a three-time turnover in leadership allowed it to balloon to 2,000. One more turnover - me - meant we didn't get to zero. Not sure if they ever did.
Close all bugs six months and older. Do it! Just close your eyes and do it. Then evaluate and aggressively close anything older than six weeks (roughly three sprints). Reasons to close can include duplicate, doesn't repro, will be resolved/replaced by future work, insufficient details. Don't over-invest yourself here; close everything that's not clearly actionable and be done with it.
If your judgement was wrong about any of those bugs (it will be), then someone will let you know and you can reevaluate at that time. No harm done. Alternatively, letting bugs linger in the backlog for months or years is poor project management and literally accomplishes nothing. It makes everything - triaging, planning, reporting, and analysis - harder and slower. It also sends a message to your team, stakeholders, and customers that quality and the user experience are not valued.
Evaluate any remaining bugs and then make a plan to fix all of them. The goal is to resolve all known bugs, so it doesn't matter if you're left with 5 or 50.
If you don't have many, then just throw in a few over the next sprints and you'll be done soon enough. If you have a lot, then plan on carving out time for bug-bashing. Order pizza, queue Metallica, and have some fun smashing bugs. When you're done, take notice of the happy customers, happy stakeholders, and that fresh clean smell!
Set expectations for "No known bugs" going forward. Despite all the must-have quality controls like linting, unit tests, integration tests, and so on, a bug will eventually find its way in your software. In fact, your team might actually do everything perfectly, but a bug can still get in due to some external factor. Regardless, include resolving all bugs and returning to no known bugs at the end of each sprint as an equal part of your toolchain. Treat it like a tool, not an idealistic concept.
There will be doubters from the very start of your effort to clean up and get to no known bugs (saw it at two companies), but don't be discouraged. They will be pleasantly surprised when you're done (and they'll copy you). After you reach zero, there's going to be the temptation to celebrate and relax, but if you're going to change the culture around quality you must have some diligence in you. There are, with very few exceptions, no good reasons for not returning to zero at the end of each sprint, so it really comes down to your team's commitment to quality and that starts with you.
I suggest always having a couple sprints ready and drop all newly reported bugs into the upcoming sprint. By sprint planning you need to have decided if any are not immediately addressable and move those to the next sprint. DO NOT BACKLOG THEM! Get answers now and make the decision now. The bug either gets fixed this sprint or next; otherwise you close as "Won't fix". Throwing bugs into the backlog for some nonexistent period in the future when the team will have magical time to just peruse the backlog for unimportant work is wishful thinking at best, but in practice it's worse than that. It leaves your team and stakeholders wondering where you stand on quality and leaves customers with a broken experience. Not good after all that progress you've made, so make your commitment and stick to it: No known bugs