Skip to main content

Is a story done even if it has defects attached to it ?

Last post 02:30 pm July 7, 2020 by Harshal Rathee
6 replies
10:21 am July 6, 2020

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 ?


02:53 pm July 6, 2020

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.


04:07 pm July 6, 2020

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.


04:55 pm July 6, 2020

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.


05:06 pm July 6, 2020

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.


06:37 am July 7, 2020

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 ;)


02:30 pm July 7, 2020

 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 ?

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.