[moconnor]

We did releases that were only bug fixes and maintenance. There can be a long tail of bugs in a complex system, most of which are relatively harmless and only occur in very rare situations; it’s hard to justify fixing these when paying customers are asking for a new feature.

Also you’d be surprised at what gets classified as a bug when you apply this.

Ultimately though, everybody does this. Critical bugs get fixed first. Anything too far down the backlog de-facto doesn’t get fixed. I like the intellectual honesty that this approach brings, in that it forces you to set a bar for bugs not worth fixing and consequently marking them as won’t fix.

Final note: whether a bug is worth fixing changes over time. Maybe your best engineer can’t find it after two weeks. Maybe your biggest customer just ran into it. Maybe you can’t reproduce it. Maybe the platform causing it got acquired by Google.

Can it work? Yes, but it doesn’t look very different to what you’re probably already doing in practice.

[orwin]

I think you can have alternative: bugs are either critical or "non-critical". Non-critical end up in the backlog, but are classed before improvements and before "non-critical" features.

How does it really work: let's say you have 2 week sprints (quite standard). Then you break the agile/scrum "story points" and velocity: it isn't usefull for your team (but might be for management). After quick estimates, each member take what he estimate to be a week, a week an a day of work on critical bugs, then critical features. Because let's be honest, you alway have more "critical" stuff to do each week, and will never get your backlog small enough to reach non-critical stuff.

Once you're done with your "critical task", depending on the time you have left, you take a non-critical stuff, in preference in backlog order if you're senior and long-time IC (lot of bugfixing), preference to "i'm sure i know how to do that" then "unknow project but seems easy enough" for juniors, and seniors who just arrived.

Having a gigantic backlog isn't an issue as long as each task are assigned to a product and a Major version: that will allows you to discard those tasks easily if the product isn't sold anymore of if the version changed.

[ozim]

It is also useful to have handful of "easy to fix" bugs on backlog to use as on-boarding for new developers .

[tagspace]

Your point on intellectual honesty really resonates.

I personally like the idea that for every bug you either: a) fix it with highest priority, or b) mark it as "won't fix".

I think this would really force you to make a decision on a bug, rather than adding it to some never ending list of lists.

If a bug is worth fixing, it will come up again

[rrwo]

Sometimes a feature request is considered a bug by customers: this product would be easier to use if we could do X, and the competing product lets us to that.

[tagspace]

Totally agree. Wether something is a bug should definitely be decided by the team, not the customer.