How to deal with Bugs in the Product Backlog & Sprints

[Daniël]

So this is the situation:
During our sprint, the QA team adds all blocking bugs as sub-tasks (we created a custom Story Bug issue type) to the linked story. So everyone has a clear understanding of what needs to be done before the story is ready for production. This works fine for everyone.

The problem:
We add all non-blocking bugs and bugs that are not related to the stories in the sprint to the Product Backlog. Which results in a big Product Backlog that's full of bugs and stories for upcoming sprints. Apart from the fact that this is messy and hard to keep track of all the bugs. 95% of the bugs just stay in the Product Backlog forever. Because we only add in the most urgent bugs to the sprint during sprint planning. Simple because of the lack of time.

The question:
How do you guys handle this kind of situation? Did anyone had the same problem and fixed it?

Thanks!

[Alan Parkinson]

I completely agree with @Nic Brough -Adaptavist- that if your backlog is forever increasing in size then the team is under-resourced. It can also indicate the product owner is valuing new functionality over the impact of the bugs and any new team member won't help bring the bugs under control

If you truly want to start working through them I would suggest reserving 20-30% of your sprint backlog to fixing bugs. This will slow down delivery of new functionality and the PO or people higher up will notice this and ask 'why'. Hopefully answering the 'why' would get you extra resources.

If the impact of the long living bugs isn't great enough for them to be fixed, do really need to keep them in your backlog? There always bugs that will never get fixed even if you had unlimited resources. Why not Identify these bugs and close them with a custom resolution of "Won't fix at this time". I use a "Best before" concept to identify these bugs - tl;dr after a period of time in the backlog close the bug because it can't be that important.

[Daniël]

@Nic Brough -Adaptavist- @Alan Parkinson thank you both for your responses. Our team is under-resourced indeed. Buth, unfortunately, finding new devs takes time. Today we started our first sprint with 30% bugs. We use the won't fix resolution pretty often. But unfortunately we can't overuse this :)

[Nic Brough -Adaptavist-]

If your bugs are never making it into sprints because of other work, that implies your backlog is growing faster than you can deal with it, which usually means your team is under-resourced.  You need more people to deal with the incoming work.