Rich Hundhausen

Issue. Incident. Outage. Defect. Bug. The mere mention of these words can send shivers up the spine of a Product Owner or stakeholder because they imply low quality. This is why I’m passionate about reducing the use of such terms or removing them from a team’s vernacular altogether. Yes, products may suffer undesirable behavior. We’ve all experienced this: a feature that used to work but currently doesn’t; an exception or unexpected halt. We might want to call those things bugs, but how does that help? Undesirable product behavior can have various causes. Are we doing more than using pejorative terms to name, blame, and shame one or more developers?

In Scrum, all work that is performed in a Sprint is called development. It serves to move toward the Sprint’s goal and deliver the forecast of selected Product Backlog Items (PBIs) as a part of that, whatever the type of work—hence, the accountability of a Development Team in Scrum. While in development—i.e., within the Sprint—there is no such thing as bugs in the Increment being developed. Perhaps the build failed due to a compilation error. Perhaps a code quality check failed. Perhaps an automated test failed. Whatever—that’s development. It is hard work with many unforeseeable problems. Within the Sprint, it says nothing more to the Development Team than that the work is not “Done” yet.

More serious problems arise when the Development Team does not have all of the skills within the team to get to Done—for example, when testing is done outside of the team by people who are dislocated by time, organization, and/or geography. This is, however, a communication problem first. A bug-tracking tool is one of the worst communication mechanisms thinkable, especially because, again, you are still in development. The identified problems are not bugs. The team just isn’t Done yet. Mind the “whole team” idea, as we do not recognize titles, sub-roles, or sub-teams within a Development Team. The collective accountability improves collaboration and transparency while reducing risk.

This is not to say that, during a Sprint, a Development Team can’t run into undesirable behavior of the product as implemented in previous Increments that were considered Done. Whether or not the Increment was actually released, I’m OK with using the term “bug.” When discovered, the Product Owner should be consulted, and in the ensuing discussion, the impact, value, and effort of fixing the problem explored. If the Product Owner deems the fix urgent, the Development Team should add it to their Sprint Backlog, with the Product Owner acknowledging that there is a likely impact on the Sprint forecast and possibly a need to reset the Sprint goal.

The Product Owner may, however, decide to wait, deeming the fix not urgent enough to jeopardize the current Sprint. The work is then added to the Product Backlog, allowing the Product Owner to consider it for a future Sprint.

Scrum doesn’t define anything more specific than a PBI as a container with a description, value, and estimate. Whether an item is a “happy” thing or a “sad” thing, it’s still work that is deemed valuable enough by the Product Owner to be performed sooner or later. All work on the Product Backlog delivers value (even if it is avoiding negative value) and has a cost, leaving it to the Product Owner to decide if the ROI pencils out.