Managing Bugs in Scrum

It’s something that people always ask ‘how do we manage bugs in Scrum?’ or ‘what do we do with the bugs at the end of a Sprint?’.  I always try to make people understand that they are asking the wrong question, what they should be asking is ‘how do we make sure we don’t have any bugs at the end of the Sprint?’.

The output from a Sprint should not be considered done if it has bugs against it. During a Sprint, a Backlog Item needs to satisfy its Acceptance Criteria before it can be considered done, therefore if any team member finds a problem that would cause the Product Backlog Item to fail its acceptance criteria then it is just another task that needs to be completed before the Item can be considered done.  As such this would result in the Item returning to the Product Backlog.

If a bug is discovered on work previously considered done it should either be fixed (if it is a trivial matter and can quickly be fixed) or if it is a significant piece of work then it needs to be prioritised with other work in the Product Backlog. Everything we do should add value, equally everything we do has a cost associated with it, in Scrum it is the Product Owner who owns the Return On Investment by balancing these considerations.

Not all bugs necessarily need to be fixed before the Product Owner will be willing to release, but this should be a business decision. No longer should developers and testers need to get into arguments about the value of fixing a particular bug. This highlights the need to have a good Product Owner who is part of the team, as they should understand the cost of not fixing the bug. If something is found which the Product Owner sees no value in fixing in the near future then there is no value in recording it, in fact it is waste to have to manage it.

If a bug is identified then two things need to happen:

1. The bug needs to be fixed

2. The team needs to investigate why the bug was introduced, and take corrective actions to make sure it can never happen again

Having a large number of bugs at any one time means that it is going to be very difficult to understand the true quality of the system and where we really are in the project. Without the second part you are never going to improve you are always going to be bug fighting, rather than building quality into to your software from the start. This may involve writing an automated test to make sure the bug never comes back, changing how team members work together or changing coding standards, once you understand how the bug was introduced you can take appropriate action.

People will argue that you are always going to have bugs due to the nature of software development, which may be true especially in a complex environment with a large team; however this is totally the wrong attitude and is the reason we have so much buggy software. Therefore we need to be careful that people don’t use this as an excuse to write poor quality software. We need to at least target ‘no known bugs’ in our definition of done and focus on building quality in. If bugs have been reported in the software and the team knows about it at the end of the sprint how can they say the story is complete? The answer should be they can’t and therefore the story should be not considered done. Focusing on good engineering practices, building quality in, and a stop the line culture allows teams to never be far from a shipable product. Good Scrum teams often find they don’t need a bug tracking system, because the question ‘how do we manage bugs?’ becomes irrelevant.

(转自：http://consultingblogs.emc.com/marksummers/archive/2008/10/15/managing-bugs-in-scrum.aspx)