Fixing Bugs in Scrum
The following post is inspired by an email I sent to our teams recently due to some confusion about when to fix bugs in Scrum.
It generated 2 responses:
1) Complete support from some (senior developer, architect and CTO) and
2) Debate and disagreement from others (Product Owners)
I will leave it to you to decide what you think. Keen to hear comments from either side. Warning: no one has swayed me in the other direction yet!
The email below….
There seems to be confusion about whether bugs should be fixed in the sprint they are found, or in the next sprint after sprint planning. Some people think that you should only fix bugs related to the stories of the sprint in sprint, and the rest should be postponed for a later sprint. I disagree. Here are several reasons why…
- Any bug represents something in the system that is broken. If it is not related to stories in the current sprint that means it’s related to stories from a previous sprint. Since in Scrum we work in priority order a bug on a previous story means a feature that is higher priority than anything in the current sprint is broken. Why would I prefer to have lower priority new functionality, if something more important is broken?
- If I postpone fixing bugs so I can ‘finish’ more stories I am skewing the velocity. If the Product Owner is using this velocity to plan what can be achieved they will get an ugly surprise when in the next sprint they can’t get as much work done because there are a pile of bugs that now need to be fixed.
- Context switching adds overheads. If someone finds a bug today it is less costly and takes less time for us to fix it immediately. If we wait till next sprint, someone has to write down exactly how to reproduce it. Then next sprint recreate it, so that it can be fixed. This is waste.
The ONLY time it is okay not to fix a bug in the current sprint is if the product owner agrees we can ship the release without this fix. In that case the bug should be closed as won’t fix, so that everyone knows that was the decision. If the Product Owner wants it fixed later they need to add it on the backlog as a story for the next release to get it fixed. It goes without saying that if they want it fixed in this release, then the best time to do it is now.