• Community
  • Products
  • Jira Core
  • Questions
  • 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.

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.

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.

 

1 answer

0 vote

>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.

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

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

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.

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.

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

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.

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Fadoua M. Boualem
Published Monday in Trello

Using Trello to manage events

As a Jira power user, I was at first doubtful that Trello could benefit my workflow. Jira already uses boards (ones you can customize!), so why would I even need to use Trello?! In this post you will...

505 views 8 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you