Bugs In Scrum — How To Tackle Them

Software is buggy — let’s admit it. Your testers, or your end users, occasionally find bugs even in production, so your product and sprint backlogs will most likely contain some of these.

Bug is something that needs to be done, but it’s not a story, which creates confusion around tackling it. Should we size it? Should we prioritize it? Should we fix production bugs right away or put them into the Product Backlog?

Sizing Bugs

Scrum is a framework which gives you a lot of space to customize the process within its limits. There is nothing said about how to size a story or a bug in the Scrum guide. There is not even a notion of a User Story. It comes from Extreme Programming.

In Scrum guide, you have a backlog item which is prioritized by a Product Owner and then pulled into the sprint based on the agreement with the Product Owner and the Development Team. Not a word about whether we need to size it and in what way.

So, there have been a lot of theories and customizations created by Scrum practitioners on top of what was given by Scrum initially. And, sincerely, some of these are really over-engineered. Sizing bugs is one of them.

Bug is something that doesn’t work. Often, you don’t know why it doesn’t. It can take 5 minutes, or it can take hours. You can’t just…