One of the key aspects of Scrum that makes teams perform better is organising the flow of work. The backlog of a team is its only source, and because it’s prioritised the team is guaranteed to always deliver valuable features. So much for theory. In reality a team has to deal with a lot of distractions that make it hard to focus on delivering the sprint goal: issues, outage, bugs, changing requirements; stuff that “absolutely cannot wait”.
Indeed, defects need to be dealt with. As a Scrum Team you face the daunting task of making sense of it all to come to a decision how to deal with a request. Luckily there are some guidelines to help you make a decision how to deal with these things.
Defect Decision Diagram
This diagram is a very easy to follow guideline how to deal with so-called defects and is universally applicable.
New Feature
It won’t be the first time that a request for a new feature is raised as a bug, either because it’s considered key functionality that’s missing or because it’s perceived as the way to get priority on its delivery. As a Product Owner you need to realise that this is just like any other feature request and should be placed on the Product Backlog and properly prioritised. If it’s truly valuable it will get done soon enough, and you will have some time to refine the feature to the point it delivers the value that is needed.
Changing Functionality
This category usually is a result from new insights, poorly specified features, or changes from outside influences that require adaptation of the product and is often discovered during a Sprint Review. These changes should be put on the Product Backlog as if it were a new feature request (because in essence it is) and be prioritised as normal.
Sometimes during a Sprint review stakeholders might call it a ‘bug’ because it doesn’t work as they had thought. It’s important as a Product Owner to ask yourself the following questions:
- Was the feature delivered as intended by the definition of its user story?
- Does the feature add value to the product for its intended user/customer?
- Does the feature have no negative effects on the other features of the product?
If you can answer these questions positively you can safely accept the feature as Done and plan to improve it at a later time.
Development Issue
Development issues are problems (impediments) that are uncovered in the course of a sprint that might disrupt the functionality of the product or endanger the sprint goal. Important to note is that these issues are discovered before the increment goes to production, so typically there is no impact to the product; if it does impact the product in production it is a Defect.
Development issues need to be resolved before the sprint ends and before the next increment of the product is put into production. Therefor the issue represents a task to be done by the Development Team and should be represented on the Sprint Backlog. Although it’s good practice to inform a Product Owner of such issues when they pose a risk for the Product Increment or the Sprint Goal, the Development Team is free to place such items on their backlog without his approval.
Defect
Finally, anything that doesn’t fall into the other categories is a defect; a problem with a product that causes loss of functionality or fails to generate value for the customer. High priority defects must be dealt with immediately and are therefor put on the Sprint Backlog; anything that is not considered high priority will be put (high) on the Product Backlog.
What is considered a high priority defect will depend per product, but often share some of these characteristics:
- Loss of functionality (key feature broken)
- Loss of availability (downtime)
- High impact for customer
Anything that will cause the acute loss of the ability to generate business value with the product can be considered high priority and should be dealt with as swiftly as possible, even if that means sacrificing your sprint goal. (in fact, sprint goals cannot generate value when high priority defects present themselves)
Anything that doesn’t fit the description above should still be treated seriously, but does not pose an acute risk for the product. They should be prioritised properly (as technical debt), preferably high on the Product Backlog, but do not warrant disrupting the current Sprint by putting it on the Sprint Backlog.
The Exception
The Scrum Guide tells us that at any given moment in time the Product Owner can terminate a running sprint. When should he consider doing this? Are defects a reason to drop everything and start working on something else?
A Product Owner should only stop a Sprint if it has become clear that the outcome of the running Sprint will not be able to result in any business value. Defects will rarely cause this scenario. In case of high priority defects it’s better for a Product Owner to negotiate with the Development Team to take this item on the running Sprint and decide (if required) what they can drop off the Sprint Backlog so that they can still reach their Sprint Goal.
In Conclusion…
Scrum is all about delivering valuable, high quality products and fixing defects is part of that. Defects should never be ignored but also shouldn’t be allowed to disrupt the flow of product development. By following these guidelines you should be able to find a good balance.
Read more
If you want to read more on this subject, please read the white paper that inspired me to write this post. (source: roneringa.com)