During our last sprint, a defect was reported against a user story from the previous sprint. I *think* we should create a new user story and plan on fixing the defect during the next sprint. Is this the right approach?
[featured-image single_newwindow=”false” alt=”Paolo Valdormon | Bug | Flickr.com” title=”Paolo Valdormon | Bug | Flickr.com”]Paolo Valdormon | Bug | Flickr.com[/featured-image]
Let’s assume that the story was released to production after the previous sprint and that the product owner accepted the work. This means that the scrum team is in the middle of their next sprint and have an established sprint goal and sprint backlog.
With these types of questions, I like to start with the scrum guide: “During a sprint, no changes are made that would endanger the sprint goal.”
According to the rules of scrum, the scrum team should treat the defect as a new PBI (product backlog item) and have it prioritized by the product owner. It can be added to the next sprint if it is ranked higher than the other stories on the backlog.
At the end of the current sprint, the scrum team should discuss the defect during the sprint retrospective and look for ways to improve their definition of done to prevent defects like the one reported from happening again.
That’s the theory. From a practical point of view, if the defect is minor AND can be rolled in to a story that is currently being worked on then the scrum development team can go ahead and fix it.
With that said, there is a common pattern that scrum development team must avoid. In these types of situations, many developers make the decision to fix the defect on their own.
The problem with this approach is that they could unintentionally impact a higher priority user story on the sprint backlog. This would put the sprint goal is in jeopardy which is exactly what we are trying to avoid.
When fixing the defect could jeopardize the sprint goal the product owner must be brought in to the conversation.
The scrum guide also supports this approach: “During the sprint, scope may be clarified and re-negotiated between the product owner and scrum development team as more is learned.”
A reported defect is an opportunity for the scrum team to learn more about their software. It is also an opportunity to work with the product owner to determine the best way to handle the defect.
All software has defects. Some the scrum team finds, other remain hidden. Some defects get immediate attention, and others can wait.
This decision belongs to the product owner.
If the scrum development team decides to work on the defect without the knowledge of the product owner, they lose transparency. Without transparency it is impossible to properly inspect and adapt the scrum events and scrum artifacts.
This loss of insight in to the development process erodes trust between the scrum development team and the product owner. Under these conditions it is unlikely that scrum teams will achieve the results that are expected from agility.
If you have a question that you would like answered, please click here to send it in.
[reminder]How does your scrum team handle defects? What issues have you had with defects being prioritized next to user stories?[/reminder]