According Pund (2013) during sprints, there are defects that are identified and have varying severities, and the [Scrum] team must make decisions to “fix in the sprint” or “push to the product backlog.” This is typically decided based on whether the developed user story still delivers business value. If a defect prohibits the execution of the functionality, thereby rendering zero business value, is not fixed by the [Scrum] team by the end of the sprint, the Product Owner will not consider the story points “delivered” and the story will not be “done.” The [Scrum] team’s goal should always be to minimize the amount of defects and several ways this can be accomplished is by collaborate with the business analyst’s to understand the requirements, collaborate with quality assurance lead to understand how the testers on the [Scrum] team are planning to test the functionality, and the developers on the [Scrum] team perform unit testing and shares those results with testers. When estimates are determined, rework (e.g. defects associated with the user story) should be included in the estimate for any user story, and is included in the story point estimate. However, there are defects that are identified that are not linked to a particular user story; for those defects, I suggest creating a “feature development” user story for each sprint, providing a story point estimate to it and linking those defects to this user story. An example of this is a defect where a query is CPU intensive. This defect was identified in production and is not linked to a user story the team has accepted into a sprint. This will require [Scrum] team resources to resolve and the team has resolved it. The original estimate was 17 hours and the actual hours was 5. OR another defect where a customer was unable to place an order on the website. The root cause was a data issue. The original estimate was 6 hours and the actual hours was 5. How are either of these defects calculated in the team sprint velocity if user story points are not assigned? I suggest creating a “Application Defect” or “Internal Work Request” user story for each sprint, providing a story point estimate to it and linking the aforementioned defects unrelated to in-scope projects, to this user story. This enables the calculation of sprint velocity for the [Scrum] team; tracks the amount of defects that are identified outside of approved in-scope project work, and allows the team to proactively address defects that are raised in production that may require immediate effort to resolve.
Your thoughts?
Bibliography:
Pund, Prashant (2013). Should Defects Be Considered User Stories. Retrieved from https://www.scrumalliance.org/community/articles/2013/2013-may/should-defects-be-considered-user-stories.
gsmithcsp 