4 Ways to Handle Defect Management During the Sprint

Read in Spanish

Scrum teams often struggle with defect management for a number of reasons: When a defect is found, does it become part of the Sprint Backlog? What if adding it to the Sprint skews the burndown, and makes it harder to meet the Sprint Goal? What if adding it to the Product Backlog delays an important fix?

An easy distinction to make has to do with when the defect is found. If it is found “during the Sprint”—that is, the defect relates to a story in the Sprint Backlog—the team makes it a task within the relevant story. If the defect was created during a previous Sprint, it becomes a separate Product Backlog Item—one that may or may not be worked into the current sprint, depending on its severity.

However, this approach gives less guidance than we might like. Not all defects are significant enough to need a task; the developer might simply fix it as part of ongoing work. And just because a defect is found while testing a story, that doesn’t always mean that it needs to be fixed right away, especially if there is disagreement about what the expected behavior should be.

Download AgileIgnite One-Pager

However, a different distinction can be made to guide defect management: is the feature “not working as designed,” or is the feature “not designed as it should work?” The former is more like a classic bug: “When I click this button, nothing happens.” The latter is a function of perspective: “I’m expecting a different behavior than the story calls for.”

But that distinction can still leave us puzzled about what to do. A classic bug that has existed in the product increment since a previous sprint might be troublesome, but should it be fixed right now? Conversely, just because a feature is working as designed doesn’t mean the behavior is desirable.

By themselves, neither distinction is as helpful as we’d like; but combining them a 2×2 matrix can guide our decision making:

Not Working as Designed, Found within the Sprint

These types of defects are usually found by the team as part of automated or manual testing while a story is being worked on, and are related to the implementation of the story.  An example might be:

“When I tap the new shape button and select a polygon with n sides, a polygon with n+1 sides is inserted on the canvas.”

What to do:

Is the defect trivial to fix? Don’t bother adding a task. Simply fix it as part of the ongoing work.

If the defect is more difficult to fix, such that it might slow the team’s progress toward the Sprint Goal, then create a task within the relevant story so that the team can make visible its effect on the team’s progress.

Either way, raise the issue in the Daily Scrum, so that everyone is aware of the problem, the progress toward fixing it, and whether or not it might cause a problem with reaching the Sprint Goal.

Ready to Start Your Agile Journey?

Not Designed as it Should Work, Found During the Sprint

This type of defect occurs when the product is behaving the way it’s expected to, based on the design or acceptance criteria, but is inconsistent with other behavior, is difficult to use, or is simply kludgy. An example might be:

“When I double-tap a shape, the properties dialog should appear, like it does when I double-tap a line.”

What to do:

When someone notices a defect of this nature, communicate the observation as soon as possible to the Product Owner and the team. Don’t wait for the Daily Scrum!

If Product Owner has a good reason to have the product behave the way it does, the worst thing a Development Team can do is change it without asking.

If the behavior really isn’t desired, the Product Owner must collaborate about whether a change would endanger the Sprint Goal. The Product Owner and Development Team may adjust the scope of the Product Backlog Item, make the design change part of a new Product Backlog Item, or simply leave it alone and wait for feedback at the Sprint Review.

Not Designed as it Should Work, Found in Existing Increment

 This type of defect is not necessarily a bug—and developers will often object if the behavior is reported as one, “I did exactly what we said!” An example might be:

“When I save my design, the thumbnail image updates to show the top layer, instead of the visible layers.”

From the customer’s perspective, a behavior that doesn’t meet expectations is a bug, even if from the development team’s perspective, the feature is working exactly as designed. Sometimes the bug report comes from outside the team—like from customers using a production release—but it can also come from quality testers on the team, who think and function as the voice of the customer.

What to do:

In these cases, create a Product Backlog Item for the Product Owner to evaluate and decide whether or not to modify the product. If the Product Backlog Item is approved, the Product Owner will decide how important it is and where it falls in the Product Backlog.

Not Working as Designed, Found in Existing Increment

The fourth quadrant represents unequivocal bugs: something that is not working as designed, and is discovered in an existing increment, or even in a production release. For example:

“When I change a shape’s color, the change isn’t reflected on the canvas until I save and reopen the document.”

Some teams are tempted to dive right in when a bug of this nature is discovered. Fix it fast, get it in the next release or in a hotfix. But just because it’s in the wild, so to speak, doesn’t mean it makes sense to work on it right away.

What to do:

A defect like this should be added to the product backlog, so the Product Owner can determine its importance and priority. The exception might be if the defect is related to a story currently being worked in the sprint, and it would be easy to fix without putting team’s ability to meet the Sprint Goal in danger. In that case, after a conversation with the Product Owner, the team might agree to add the defect to the Sprint, often by expanding the scope of the existing story to cover that bug.

It’s all about communication

Communication between the Product Owner and Development Team is key to Scrum defect management. Individually, none of the quadrants is a slam-dunk: even a “not working as designed,” found as part of Sprint work might be disregarded (if it makes sense to incur the technical debt for the short-term) and be moved into the Product Backlog. The point is that you don’t want these defects to run amok, or to assume that all defects have the same resolution. By understanding what they are, where they come from, and how they can be fixed, you can stay on track with your Sprint Goal.

Want more tips on how to make your Sprints run smoothly? Check out our other blog on how to tackle Sprint work that ends early.

Interested in learning more about agile transformations? Download the AgileIgnite One-Pager.