Avoiding technical debt from bugs – From Scrum to Kanban

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?


  1. Scrum is not antithetical to the notion of completing a story! If you don’t finish a story (and that means testing it too!) within a Sprint, you are not done with it. If it’s not done, it doesn’t get counted within that Sprint and goes over to the next one. The problem here, it seems, isn’t the methodology but the idea that testing and “sprint work” are separate things done by different sets of people.
    Don’t get me wrong, Kanban boards and WIP limits are fine tools and perfectly compatible for use within the Scrum framework.

    1. Thanks for the comment. You are right. Although we have always tried to treat QA as part of the sprint work there is often a lag of a few days that we need to address. Using Kanban has only made that more visible and forces to stop coding and start helping the testers when there is a problem. I’m missing the fixed length nature of Scrum and we may well end up combining the two.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: