Agile Defect Fixing

I just read a posting on AgileBuddy about accounting for bugs in an Agile world. The post talked about accounting for bugs, team capacity, and whether bugs should count in team velocity.

It is very clear to me, both from the literature and from experience, that you should account for defect work done in the sprint. You must account for all the work done, otherwise you set false expectations for your business partners, for other stakeholders, and for the team itself (creating a tendency to over task and over commit). There is more than one kind of defect however and they don't all need to be treated the same.

Defects found during the sprint that are a result of coding done during the sprint (sprint defects) should be part of your normal code/fix work. We don't track hours or points for these because they are part of the original story point/task hour plan. This does mean that you have to think about that during sprint planning. We should be planning on code quality, requirements clarity, and the things that create less defects too of course.

Defects found that are not a result of the sprint or that are found during the sprint and the team/PO chooses not to fix them (based on time and priority), are put into the backlog for future sprints. These need to be prioritized by the PO and estimated just like any other backlog item.

If a defect is planned to be fixed during the sprint, we consider it part of the sprint backlog and it gets counted in the velocity. We typically add a "bug" story that gets x number of story point assigned to it, then we add defect tasks that approximate the story point estimation. This allows us to keep working on defects that are found at other times or by other stakeholders/customers.
I don't think that punishing the team by not including their defect work in the sprint is productive. We have a lot of legacy code that the teams are not the originators on and to make them accountable for previous years mistakes (before Agile) doesn't make sense. I do however believe it's important to keep the team accountable to their commitment of story points and to completing the sprint defect free. The basic point is that the team working on an issue, isn't necessarily the one that created it (which can cause mixed feelings and eventually a lack of productivity).

Agile and QA is an evolving process for us, but as we move toward more automation and more consistency in our Agile implementation, we're starting to see better and better results. There is much more to say about defect management in Agile to be sure, stay tuned.