Managing Defects Found During a Sprint

Under the Waterfall software development methodology the typical lifecycle includes Design, Coding, Testing, and Deployment where the separate stages occur in sequence with some parallelization of work depending on the project and organization.

As the name implies and process diagram illustrates, the majority of defects are found later in the process after coding has finished. Then the cycle of testing, fixing defects and retesting continues until a sufficient level of quality has been achieved so the project can be deployed.

However, under the Scrum methodology, coding and testing are closely integrated such that defects are found much sooner and there’s an opportunity to address them quickly.

When a defect (D1) is found for new code introduced in the current sprint, the general rule is “no defect escapes the sprint”. This means that it should be fixed before presenting the backlog item to the Product Owner for Acceptance during the Sprint Review meeting. If the Developers feel the defect is trivial in terms of severity or impact, they can share their viewpoint with the Product Owner who may agree to defer it to the Product Backlog.

When a defect (D3) is not associated with the code being touched in current sprint, the
Developers should bring it to the attention of the Product Owner and allow him to prioritize when it should be addressed. If it is important enough to fix within the current sprint, the whole team (Developers and Product Owner) can negotiate how to get it done. This negotiation may require changing current sprint scope to accommodate it but if the disruption is too great, the Product Owner may decide to wait and add it to the Product Backlog for a future sprint.

Often such decisions aren’t so black & white and a defect (D2) may be related to current sprint work but require more time than is available to fix it even with negotiated changes to sprint scope. In this case, the team will defer it and the Product Owner will add it to the top of the Product Backlog to ensure it gets picked up in the very next sprint. This action allows the team to finish the already planned sprint scope and start afresh in the next sprint.

Whatever decision is made, it is important that the circumstances and decision regarding a postponed defect are documented along with the defect details so future reviewers of the team’s activities and Product Backlog can understand the decisions made at the time.

© 2012 William Patrick Swisher

Advertisements
This entry was posted in agile, Backlog Items, defects, Flexibility, product backlog and tagged , , . Bookmark the permalink.

3 Responses to Managing Defects Found During a Sprint

  1. Pingback: What to do with defects found in sprint | Agile Thoughts Blog

  2. tushar says:

    Hi, thank you for this post I agree with you that Under the Waterfall software development methodology the typical lifecycle includes Design, Coding, Testing, and Deployment where the separate stages occur in sequence with some parallelization of work depending on the project and organization. very useful information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s