Bugs, flies, mosquitoes are common in most countries. And some of these bugs are found even in our code!!!
Even though we try our best to prevent bugs, sometimes these bastards make their way in the cool software we produce.
So, when do we fix them?
It all comes down to one golden word. No, that word isn’t “now”. It’s Priority.
This Product Backlog is always arranged by priority – highest priority stories at the top and lowest at the bottom.
You work in Sprints while picking up new stories from the top of the Product Backlog. This would also include bugs if they are high priority ones.
So in a typical Sprint Planning, you would pick some items from the top (they could be a mix of stories and bugs), estimate them, and then go about working on them during the Sprint.
But what about the bugs that are discovered during a Sprint?
Guess what, the answer is Priority!
Let’s say you are in the middle of a Sprint with 2 days left, you have completed 3 stories and are left with 1 story. Suddenly the QA angel comes to you with 3 bugs.
But what to do? You don’t have enough time to work on the pending stories AND the bugs. So you seek PO’s/PM’s help in prioritising.
Maybe the bugs are critical. If you don’t fix them, then the stories they pertain to are useless. In this case, it might make sense to work on the bugs instead of the stories.
Maybe the bugs are not so serious and can be attended to later. Maybe you can send them to the client as “known issues”. In this case, you put them on the Product Backlog where they get prioritised for the next Sprint (or even later).
Or maybe, if time permits, you work on one of the 3 bugs raised that was critical but wouldn’t take time. That ways you can complete the remaining stories and fix the bug. But if it isn’t so, then you prioritise.
When in doubt, talk to your PO/PM for priority. They would help you decide which is more important – the bug fix or new functionality.