Bug Burndown

We are currently in the end game for one of our internal development milestones.  We completed feature work a few weeks ago and are now in a mode of final cross subsystem integration, completing test development, and wrapping up bug fixing.

 

What practices, if any, of Scrum should you use during this phase of development?  The sprint planning doesn’t amount to much for developers as you don’t know what your incoming bug rate is going to look like for a team.  You can set a goal for a sprint, but it’s not something that the development team can feel a lot of ownership in.  The sprint timeframe may not align very well with the planned exit.  The traditional hours based burndown chart is of very limited value.

 

On the other hand, communication is still important and the daily meeting can be very beneficial.   Impediment removal and other ScrumMaster responsibilities are critical.  Sprint retrospectives are just as important now as they are during other parts of the milestone.  And we do have a goal and a timeframe, but what Big Visible Chart can we use to monitor the goal and provide feedback to the team?

 

The answer that a couple of teams have used for this milestone is a Bug Burndown Chart.  It looks like a typical burndown chart, but it plots the number of remaining bugs on a daily basis instead of hours.  We actually plot multiple lines on the chart to show bugs with different priorities as well as the total count.  The ScrumMaster updates the spreadsheet daily by pulling 4 numbers out of the bug database.  The Test team, which is also part of the Scrum team, has a similar chart showing the number bugs to re-test.

 

While I’ve informally done a bug burndown on previous releases, this is the first time that I’ve formalized it and made it visible to the team on a daily basis.  The Bug Burndown Chart has been a good indicator of our progress and it’s something I will continue to do for the end game of future milestones.