Is a story done even if it has defects attached to it ?
Dear all,
i have a question regarding defects detected during a sprint. If while testing a user story, defects are detected, it seems logical to open bugs about them. But what do you do with the user story at the end of the sprint ? Should it be closed ? Or deported to the next sprint even if there is nothing left to do on it except work on its bugs ? And in that case, what do you do with its story points ?
Or deported to the next sprint even if there is nothing left to do on it except work on its bugs ?
@Clément Berger, It doesn't look like there is nothing left to do if it still has bugs, right? Would you consider it as meeting the Definition of Done?
And in that case, what do you do with its story points ?
Story points have no purpose other than for planning. If the work is incomplete by the end of the Sprint, its story points are not counted as part of the velocity. If the incomplete item is going to be completed next Sprint, then you'd re-estimate it and put the item back into the Product Backlog. Here's the quote from the Scrum Guide.
All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
Hope that helps.
Like most things, it depends. Assuming that the User Story is the Product Backlog Item, are you going to incorporate that User Story with known issues into the potentially releasable Increment?
If you are going to incorporate the work into the potentially releasable Increment, then I would recommend treating the User Story the same way that you treat any other Done User Story. However, any known issues or bugs would sit on the Product Backlog and be ordered with all of the other work. By releasing with known issues, you are making the conscious decision to incur technical debt in the form of these bugs in order to get feedback on the working aspects of the User Story.
If you aren't going to incorporate the work into the potentially releasable Increment, then I would treat the user story as you would any unfinished Product Backlog Item.
If while testing a user story, defects are detected, it seems logical to open bugs about them. But what do you do with the user story at the end of the sprint ? Should it be closed ? Or deported to the next sprint even if there is nothing left to do on it except work on its bugs ? And in that case, what do you do with its story points ?
Because a Sprint should result in a releasable Increment, are the defects found on that Increment (as opposed to finding them earlier)?
If so, then the first choice might be between accepting or rejecting the entire Increment.
As for the individual user story, if there is remaining work to be done, options could be:
- Close the user story and include it in the Increment (if that complies with the definition of "Done")
- Abandon all work on the user story, and move on without including it in the Increment
- Continue working on the user story in the next or a later Sprint
I won't answer your question about story points right now, other than to say Scrum has no explicit rule about estimation, and the Development Team should use the method that best enables Inspection & Adaptation. There are lots of opinions on estimation, and that could be an entire topic of its own.
i have a question regarding defects detected during a sprint. If while testing a user story, defects are detected, it seems logical to open bugs about them.
I'd suggest otherwise. If the work hasn't yet been released, then logically no associated defects can have been introduced into the product.
Rather, the team will have identified additional things to do before the work in progress is "Done" and of release quality. New tasks may have been uncovered, for example, such as rework. These should be estimated to show the true amount of work remaining.
The team should collaborate to complete all emergent tasks, including any rework, and inspect and adapt their Scrum implementation so future waste is avoided.
In short, there are a few concepts to consider: 1. the increment (sprint outcome) should be releasable into production, 2. The Definition of Done states the conditions of when something is Done, 3. The quality of the increment should not be reduced by a new increment
Given the above, it should be easy to find your answer ;)
But what do you do with the user story at the end of the sprint ? Should it be closed ?
What does your DOD say & does this story meet your DOD ? The additional work that came while testing the story how important is it for an increment to be released without degrading the quality ?