Does your development team treat defects differently? A few projects ago the sprint teams I worked with decided the best way of burning down the bug list was to allocate at least a day a week (or every two weeks) to defects. There were several sprints running in parallel with a continuous daily build. The main sprint’s stories took priority so non critical defects built up. Come defect Thursday everyone dropped the new tasks and picked up the bugs.
Over several weeks the burn-down charts showed progress with reduced defects along with the main stories. With the weekly expectation of having to focus on defects the sprint teams adopted a more ‘relaxed’ approach to bugs. Of course the critical bugs took priority in the daily stack but the medium and low priority defects were left for Thursdays. This allowed more time to think through a better fix. Thursday’s stand-up could home in on areas that needed refactoring to fix the defect and maybe adopt a better strategy for exception handling or tackling the buggy UI component that had been accepted until now.
Compared to some other approaches to managing the defect list such as daily developer rotation (oh no it’s not my turn) or swot team (the ‘B’ team – always bug fixing) having a fixture in the calendar my work for you too.
