One of the challenges of Scrum is being really done when you think you are done. At the end of the sprint our testers often haven’t had the chance to fully test all the stories. Once we are on the next sprint it is disruptive to go back to older stories and fix the bugs, so they often sit in the bug log and become technical debt.
Scrum discourages distractions from the sprint work and this helps us to focus and not have to multi task. This means when new bugs are found (often nothing to do with recent sprints) they tend not to get dealt with immediately and again accrue technical debt. If our team were to release tomorrow we would be releasing with about 3o known bugs. Ouch.
How can we avoid this situation? Well for the past few months we have been leaving a gap between sprints to fix up any outstanding bugs but it doesn’t work particularly well. People see it as down time with no clear goal or process and it tends to be pretty unproductive.
Really we should be treating bugs as high priority stories, and put them on the sprint. But fixing bugs on sprints never feels right and detracts from the sprint goal. Bugs are also very difficult to estimate making sprint planning difficult.
So what about abandoning Scrum and moving to Kanban? On a Kanban board a story can’t be truly done until it has been fully tested and is bug free. Limiting Work in Progress means that we can’t pull in new stories until the current ones are truly done. The visibility of buggy stories holding us up should really focus our attention on improving our quality and stopping them appearing in the first place. Any new bugs found that are unrelated to current stories can enter the backlog as priority tasks.
Could Kanban be the beginning of the end for our bug log?