You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
How do you guys handle this kind of situation? Did anyone had the same problem and fixed it?
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.
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.