Does adding new features bother you when existing features have bugs?
Me too.
Managing software projects used to feel like I was a car salesman throwing in an unnecessary set of winter tires 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 has matured, this feeling hasn't changed. I just can't bring myself to excuse or minimize existing bugs.
Some years ago at the direction of the CTO, I had an opportunity to pursue bugs with extreme prejudice and my team eventually whittled our backlog bug count down to zero. It felt 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 bugs lingering in a backlog.
Our commitment to No known bugs
Achieving truly bug-free code is unlikely, perhaps even impossible, but reaching a point of no known bugs in your software is very possible. Two other teams of mine brought their shared backlog down from 600 bugs to about 50* and I've had four other teams get down to zero and regularly return to zero at the end of each sprint. Again, this did not mean our software was completely bug-free - that was not the goal - but it did mean all known bugs were quickly resolved.
This commitment to quality did a few things for us.
First, it just felt good knowing we had cleaned house and customers were no longer experiencing those issues. It made our work more rewarding and energized the team.
Second, it sent a signal to everyone that this team cares about quality. That we want what's already been built to be as good and perfect as the new stuff we're building. It also gave folks a clear picture on the state of our product quality because the backlog accurately reflected it.
And lastly, this practice made triaging tickets more meaningful because we could honestly evaluate every incoming issue without ignoring old bugs or carelessly sweeping new issues into the pile. No known bugs in the backlog means there's no question about what's most important: that newly discovered bug is the one and only priority. Easy.
*Among other things, a four-time turnover in leadership allowed the backlog to balloon to over 2,000 tickets. One more turnover - me - meant we didn't get bugs down to zero. Not sure if they ever did...
So, how'd we do it?
In a backlog of over 2,000 tickets there were 600 bugs. We got it down to 50 and my others teams reached zero. This is what we did:
1. Close old bugs now!
Close all bugs six months and older. Do it. Just close your eyes and do it! Then, take a moment to evaluate and aggressively close anything older than six weeks (roughly three sprints). Reasons to close these include duplicates, doesn't repro, will get resolved/replaced by future work, and insufficient details. Don't over-invest yourself here; close everything that's not clearly actionable and be done with it. You will doubt yourself here - don't! Pull the bandaid.
If your judgement was wrong about any of those bugs, then someone will likely let you know and you can reevaluate at that time. No harm done. Letting these bugs linger in the backlog for months or years is worse. It's poor project management and literally accomplishes nothing. It makes everything - triaging, planning, reporting, and analysis - harder and slower and less accurate. It also sends a message to your team, stakeholders, and customers that quality and the user experience are not valued. So, close these old dusty bugs to kickstart your path to no known bugs.
2. Fix the rest of the bugs
Examine the remaining bugs and make a plan to fix them all. No, not a mental note to get around to it. Write down an actionable plan to fix these bugs. The goal is to resolve all known bugs, so it doesn't matter if you're left with 5 or 500. They are finally getting fixed and you're gonna make a plan to do it!
If you don't have many bugs, 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(s) for dedicated bug-bashing. Order pizza, queue Metallica, and have some fun smashing bugs. When you're done - when you have zero bugs in the backlog - take notice of the happy customers, happy stakeholders, a proud team, and that fresh clean smell!
3. Next, set expectations
Setting expectations for "No known bugs" going forward is critical. Despite all the must-have quality controls like linting, unit tests, integration tests, and so on, a bug will eventually find its way into 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.
I've found having two sprints created at all times - the current sprint and the next sprint - is a simple and effective way to slide any new bugs right into a sprint. They never actually go to the backlog. I consider making features customers are already using perfect as important as giving customers new features. In other words, I don't view fixing a headlight and installing winter tires competing priorities. They're both happening, no question about it.
4. Be diligent
There will be doubters from the very start of your effort to clean up and get to no known bugs (saw this at two companies), but don't be discouraged. They will be pleasantly surprised when you're done (and they'll want to 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 strongly recommend 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 it as "Won't fix". Throwing bugs into the backlog for some nonexistent time in the future when the team will have magical time for perusing the backlog for 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