This question was asked in an online forum(I’m paraphrasing):
> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress? Like ones that take weeks to solve?
In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.
I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.
One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog. Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs. This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing. The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.
The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software. I would argue that this is not a sprint killer. It is simply a fact of complex software development.
The real issue comes down to this: Scrum transparency is trying to tell your team something. What is it trying to tell your team? What is your team going to do about it?
- Looking for Agile/Scrum/Kanban Coaching or Training? Contact us for more info. We have some good specials going on right now, but they won’t last long!
- Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc. Feb 28th in the Denver Tech Center. More info and sign up here!