Now, sprint is closed.I have tried to see burndown chart and found that it shows scope change at couple of place. After analysis we found that if we log any defect while testing of user story it shows as scope change.

[Dnyaneshwar Ramesh Borase]

Today I have closed the Sprint.I have tried to see burn down chart and found that it shows scope change at couple of place.  After analysis we found that if we log any defect while testing of user story it shows as scope change. In reality it is not scope change, it is part of user story. As per our DOD, testing/defect fixing should be complete within sprint.

Please let me know if you have any guideline for handling the defect of user story in active sprint.

[Nic Brough -Adaptavist-]

>In reality it is not scope change,

I'm afraid it is, because you're bringing new work into the sprint.

You either have to accept that, or move the work into the next sprint.

[Dnyaneshwar Ramesh Borase]

But after starting a sprint you can not add/delete issue in starting sprint.

You can create sub-task within the story.

Here in my case:

In active sprint there is 3 stories with story points

In that stories I have created sub-task for developer.QA team will test & find 2-3 defect for the story then they will create defect in active story.As per our DOD, testing/defect fixing should be complete within sprint

[Nic Brough -Adaptavist-]

Yes, and those defects are new work so you're changing the scope.

[Sten Sundelin]

I think that if those defects are found before the Demo has been accepted (and the Story is 'Done'), you can just communicate internally using comments on the ticket - it is not necessarily scope change but part of developing the story. Depending on your workflow for the story, you might want to "pull it back" a transition or two.

If the defect is identified after Demo has been accepted, however, I agree with Nic that a Defect should be created and it is scope change.

[Nic Brough -Adaptavist-]

Very true, to avoid this, you could "pad" your stories while estimating them before pulling them into a sprint.  Have a look at the previous stats for how much you added into the sprint as a result of adding the new defects into it and then increase your story estimates by the amount.  Then you won't need to add to the sprint.

[Dnyaneshwar Ramesh Borase]

Thanks for the advice.

I have one query on this,Please let me know how to handle the defect once it is created for user story in active sprint?

1. Can I create Defect in defect backlogs which is another project & link that defect to the user story.
   or
   create  a sub-task for this defect within a user story & linked to the defect which is created in defect backlog project

thanks

[Nic Brough -Adaptavist-]

We've discussed most of that above already, but to add to it, yes, a linked issue is the best option.  Where it goes is up to you and your processes really.