Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


How to deal with Bugs in the Product Backlog & Sprints

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?



2 answers

3 votes
Alan Parkinson
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Sep 22, 2017

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.

@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 :)

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Sep 20, 2017

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.

Suggest an answer

Log in or Sign up to answer