The Bug Bash Sprint
In every Sprint we do, we try very hard to produce the highest quality software possible. However, we’re all human and we still produce software with defects. On one of our current projects, we had reached a point at which our Product Owner wanted to demo the software we had developed so far to his statewide GIS coordinators. He set the priority for our next Sprint to be to fix any defects in our defect list so he could have a smooth demo. We agreed, but also made sure we included a few small pieces of functionality that we could develop to meet our goal of producing some potentially shippable product increment during each Sprint.
Since we made our move to Rally Software, managing our defect list has become much easier. And moving defects from our defect list to our Sprint backlog was even easier. After we had filled our Sprint backlog with all of the bugs that we estimated we could fix in our two week Sprint, we created a set of tasks for each defect. The minimum requirement for each defect was that we would verify the defect, fix the defect, test the fix, and have an in-house Product Owner proxy verify the fix.
We were quickly moving through our Sprint backlog and it looked like we’d finish very far ahead of our ideal burndown for the Sprint. We decided that one of our developers would take a look at any new, incoming bug reports from the customer, triage the defects, and create new tasks in the Sprint on an ad hoc basis. At first, I thought this might not be the best idea, and it sort of goes against Scrum’s “rule” of not adding new work during a Sprint. However, given our burndown rate and our success at bashing the other bugs at that point in the Sprint, we thought we should really try to fix as much as we could for our customer’s demo. We told our customer that the Friday at the midway point of the current Sprint would be the cutoff for defects that we could address in the current Sprint. We suddenly received a flurry of defects before the deadline, but nothing that was too hard to handle.
Our developer did a great job triaging the defects as they arrived. We decided that anything that was an enhancement would be placed in the project backlog to be prioritized at a later date by the Product Owner. High priority bugs, as defined by the Product Owner, were placed in the Sprint backlog. We triaged, fixed, tested, and verified nearly every bug. At the end of the Sprint, we successfully fixed all of the high priority bugs in our defect list.
One of the unexpected benefits of this bug bashing Sprint was the knowledge transfer we experienced between developers. Because the tasks were so short in duration, our developers were picking up lots of tasks quickly, and most had nothing to do with the functionality they had developed. This in turn created a need for more communication between our developers than usual. This gave them a much better and deeper understanding of our entire codebase.
At our Sprint retrospective, the development team expressed a high level of satisfaction with the Sprint. They were very happy to have the opportunity to understand each other’s work on a deeper level. The team also decided that instead of fixing defects in drips and drabs, they preferred fixing them in one dedicated bug bashing Sprint before each release. They thought the benefit of the knowledge transfer, and the ability to focus on just defect fixes was significant enough to do more bug bashes in the future. This was a huge indicator for me that our team was really grasping the “inspect and adapt” mantra of Scrum. They had thought about what made this Sprint so productive and decided that it was a practice worth keeping. The bug bash Sprint was a smash for our team. Maybe it can be for yours as well.
© Copyright 2007, ChrisSpagnuolo.com GeoScrum! by Chris Spagnuolo is licensed under a Creative Commons Attribution 3.0 United States License.
Hi there–found your blog when researching another topic and have enjoyed reading a few articles. I wanted to make one comment here based on something you said:
” and it sort of goes against Scrum’s “rule” of not adding new work during a Sprint”
I would assert that Scrum has no such rule as I believe that Scrum states that the only entity that is capable of adding work is the team (as opposed to the ScrumMaster, Product Owner, or other various chickens). I realize that you had this in quotes, but I just wanted to eliminate any confusion for potential Scrum newcomers.
Keep up the great work!
MattR
Add A Comment