Every release, our trail of bugs keeps on increasing. These are valid bugs however, we also have to write new features to stay in the competition. Also, those features will be more used than the bugfixes; and provide better ROI.
How are other engineers and product owners handling this situation?
At a technical level, bugs, features, it's all the same, a change request. Do you ever decide not to add a feature because it's not worth it? It's the same with bugs. The only difference between bugs and features is commercial - 'customers' pay for features, the 'company' pays for bug fixes, or something like that.
However, as with feature requests, every bug report needs a change tracking ticket. The ticket must be as easy to close as it is to open. That is the only way you will capture the data you need to make decisions.
Change requests should be closed as quickly as possible. The reason for this is open requests take time to analyze, clog up the system and add little value. You need to quick way to decide that you won't do it, and once that decision is made, close the ticket. You should aim to never discuss if an item should be open or closed more than once. One of the biggest problems I see it the reluctance of people to close a ticket "Will not fix", so they leave it open. If you ain't gong to fix it, be honest to everyone and just say "We ain't going to fix that, get over it."
Have both Priority and Severity in your ticket. The effect of the defect on the system is it's severity, sales and marketing set the priority.
Other tips: Use a figure (say 20%) from the budget of feature requests/enhancements for fixing bugs. (i.e. if I do 10 days adding features, I do 2 days fixing bugs). Bugs are fixed in Priority order till the budget is spent. This gets around the commercial drive for features only development.
The cost of a defect is exponentially proportional to the time between insertion of the defect and fix (Or decision not to fix) of that defect. To prevent those niggle bugs costing disproportionate amounts of $ because you don't fix them, and refuse to close them, open tickets have their priority raised on a regular basis (Say 5 priority levels - once a month), and cannot be lowered. That way, you will be forced to deal with it within say 6-12 months.
You should have a triage and priorities meeting on a regular basis.
At my previous job we used to have a weekly meeting that consisted of product owners and the dev lead (me). We would
The goal was to make sure there was a balance in what we worked on. I would explain the cost of ignoring certain problems and how much they would cost down the line. I would also explain the development cost for each change and offer up alternatives when appropriate. In return I would get a sense of the importance of certain features to the business. This provided both myself and the product managers with
Once a rapport had been established, the meetings went by quickly with few disagreements.
Keep a database with all the bugs and bug reports and deal with them when new features stop being as relevant, while trying to focus the bugs that happen most often and with the most impact on the program.
