It is common while testing a user story, defects are detected. Of course, no one wants to release increments with defects, and they should fix before releasing in production, but what if they identified at the end of the sprint? How should these defects be addressed in Scrum? Should it be considered done? Should it be considered an unfinished user story? How quickly should the defect be treated and with what urgency? Should defects be added to product backlog as PBIs, regardless of whether they need to be immediately fixed or can be deferred?
What is defference between defect and bug?
Regarding to the What is difference between Defect, Bug , Error ? by Nikita Gupta, “A Bug is the result of a coding Error and A Defect is a deviation from the Requirements. A defect does not necessarily mean there is a bug in the code, it could be a function that was not implemented but defined in the requirements of the software.”
What does the Scrum Guide say?
Although a particular solution to fix a defect during a current sprint is not recommended in the Scrum Guide, it clearly explained the definition of “Done”. Referring to the Scrum Guide, a definition of done is a shared understanding of expectations that the increment must meet to be released to the production environments.
On the other hand, in the Scrum Guide, the Development Team defined as professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. They are self-organized which means that no one (not even the Scrum Master) tells them what to do.
How to handle defects?
Although any known defects and bugs, would remain on the Product Backlog and be ordered with all the other PBIs, still it’s up to the Development Team to consider about the newly identified defects based on the following criteria:
- The Definition of Done clearly explains the conditions of when a user story is Done.
- The Quality of the increment should not be reduced by any defect.
- The Increment should be released into the production environment.
- The Development Team aware to get feedback on the working aspects of the User Story, they make the deliberate decision to incur technical debt in the form of these defects by releasing known issues.
Based on my previous experience, the Development Team would have negotiated with the Product Owner to decide what to do with those defects. If the defect is not sufficiently severe to prohibit the Sprint Backlog item from being accepted, then it can be closed.
Regardless of whether the Development Team, accept the User Story with identified defect(s) as Done or no, still it’s there responsibility to talk about it in the Retrospective meeting to see how they can prevent this in future sprints.
Please share your thoughts with me on this.
Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
Leave A Comment