While most of the scrum teams today are equipped with next-gen defect management tools and relevant skills, they face defect management challenges daily when addressing questions like, “Would a defect become a part of sprint backlog when found?”, “What if adding to the sprint skews the burndown and makes it difficult to achieve sprint goals?”, and “Will an important fix be delayed if added to the product backlog?”
Answers to questions like these lie in the timing of defect detection. If it’s found “during the sprint” – that is, the defect is relevant to some story in sprint backlog – the team then changes it as a task within related story. Whereas, the defect created during the previous sprint becomes a separate item in the product backlog.
This approach is, however, insufficient. Some defects are not significant enough to require a task and can be fixed by developers since it is like ongoing work. And because some defect is there while a story is being tested, that doesn’t necessarily mean that you need to bring defect management tools in play to get it fixed immediately, specifically if there has been no agreement regarding the expected behavior.
However, to guide defect management, a different approach can be made: Is the feature “not designed as it should be?” or is it “not working as designed?” The former is a perspective’s function: “The story calls for a different behavior than expected.” Whereas the latter is similar to a classic bug: “Nothing happens when I click this button.”
This distinction can leave us confused. A bug that existed in product increment from a previous sprint may be troubling, but does it require immediate treatment? Similarly, because the feature works as designed, it doesn’t mean that the behavior is desirable.
Found within the Sprint, Not Working as Designed
These issues usually occur while working on some story by the team as part of manual or automated testing. For example, “Upon tapping the new shape button and selecting a polygon with n sides, a polygon is inserted on the canvas with n+1 sides.”
Solution:
Don’t add a task if the defect is trivial to fix. Simply redo it as a part of on-going work. Create a task within a related story if the defect is difficult to redo, such that it may slow up the team’s methods towards the sprint goal. This way, the team shows its impact on the progress. In any case, raise the issues in daily scrum so that all are aware of this problem, the progress towards fixing it, also, whether or not it may cause some problem with accomplishing the sprint goal.
Found During the Sprint
Defects of this type occur when products are behaving as expected, according to the acceptance or design criteria, but is difficult to use, inconsistent with other behavior or simply kludgy. For example, “Upon double-tapping a shape, the properties dialog should appear, like it does when a line is double-tapped.”
Solution:
Upon noticing the defect, communicate about it immediately to the product owner and the team without waiting for the daily scrum. If the product owner addresses it to behave like that, it’s not a good idea at all for the development team to change without asking.
If the behavior isn’t desired, the product owner should collaborate and address if the change is needed or if it endanger the sprint goal. The development team and the product owner may make the design change part of a new product backlog item, adjust the scope of the product backlog item, or simply await feedback at the sprint review and leave it alone.
Found in Existing Increment, Not Designed as it Should Work
Defects of these types are not necessarily bugs – and if the behavior is reported as one, the developers will end up objecting. For example, “When I’m saving my design, instead of showing the visible layers, the thumbnail image is updated to show the top layer.”
From the perspective of the customer, a behavior failing produce desired outcomes is a bug, even if the feature is working exactly as designed, from the development team’s perspective. On some occasions, the source of bug reports is not the team – it may be customers using a production release – but quality testers on the team also play a part by functioning and thinking as the voice of the customer.
Solution:
In cases like these, create a product backlog item for the product owner for the evaluation and decide whether the product needs modification or not. The product owner will decide how important the product backlog item is and where it falls in the product backlog if it’s approved.
Found in Existing Increment, Not Working as Designed
Lastly, these are the unequivocal bugs that are not working as designed and are discovered in an existing increment, or even in a production release. An example might be, “Upon changing the color of a shape, the change isn’t reflected on the canvas until the document is saved and reopened.”
Some teams attempt to fix these kinds of bugs as soon as they are discovered. But to work on them right away is not a good idea.
Solution:
For the product owner to determine the priority and importance of a defect like this, it should be added to the product backlog. In a least likely scenario, it would be easy to fix a bug without hindering the team’s progress towards a sprint goal. In that case, upon conversing with the product owner, the team may end up agreeing to add the defect to the sprint, often by scope expansion of the existing story for covering that bug.
It’s All About Communication
Defect management tools play an imperative role in enhancing the collaboration between the teams. Communication between the development team and the product owner is crucial for scrum defect management. Individually, there’s no certainty regarding any of these defects: even a “not working as designed”, might be dismissed and moved into the product backlog. The last thing you want from these defects is to run out of control, or to assume that all defects have the same resolution. You can stay on track with your sprint goal by understanding their nature, their origin, and how they can be fixed.
Conclusion
Defect management in Scrum is a complex process, but it can be made more effective by following a few key principles:
- Communicate early and often. The development team and the product owner should be in constant communication, especially when it comes to defect management. This will help to ensure that everyone is on the same page and that defects are prioritized and addressed in a timely manner.
- Use a defect management tool. A defect management tool can help to track and manage defects throughout the development process. This will help to ensure that defects are not lost or forgotten, and that they are fixed in a timely manner.
- Prioritize defects carefully. Not all defects are created equal. Some defects are more critical than others, and some may even be acceptable to leave unfixed for a time. The product owner and the development team should work together to prioritize defects so that the most critical ones are fixed first.
- Be flexible. Things don’t always go according to plan in Scrum. Defects may be discovered at any time, and they may require changes to be made to the sprint backlog. The development team and the product owner should be flexible and willing to make changes to the sprint backlog as needed.
By following these principles, teams can improve their defect management process and deliver higher quality products to their customers.
Additional Tips
Here are a few additional tips for effective defect management in Scrum:
- Use a standard defect classification system. This will help to ensure that defects are classified consistently and that everyone is on the same page.
- Track defect trends. This can help you to identify areas where the team needs to improve.
- Use defect metrics to measure your progress. This will help you to see how you are doing over time and to identify areas where you can improve.
- Use retrospectives to identify and address root causes of defects. This will help to prevent defects from happening in the first place.
Defect management is an important part of the Scrum process. By following the tips above, teams can improve their defect management process and deliver higher quality products to their customers.
