Sub task, Task and defect is adding as scope change in Burn down chart.

[Rakesh Prashanth]

Hi team, 

after a sprint is started, our team creates defect / tasks in the sprint. This creates scope change to the sprint in the burn down chart. need to exclude these issue types from burndown chart scope changes. 

can any one suggest how to overcome this issue and explain the traditional process in jira. 

[Dave Mathijs · Accepted solution]

Hi @Rakesh Prashanth welcome to the Atlassian Community!

But they are a scope change as work has to be done to fix the defect or complete the task within the sprint. Any issue type added to the active sprint is scope change.

[Rakesh Prashanth]

Hi @Dave Mathijs  Agreed!

so we should be adding story points to those defect / task and once they are burned, chart will narrow down as and when those issues are closed correct?

[Dave Mathijs]

If you handle an issue in a sprint and you are using story points, then story points should be added before the sprint starts. 

If your estimation is based on Story Points, and you assign 0 story points to those issues, they will still be considered scope change, but there won't be any change in burndown if you complete them.

[Nic Brough -Adaptavist-]

You don't say anything about the types of these issues, but I wanted to add the point that you should never put scrum estimates on sub-tasks - that will also break your burn-down.

[Bryce Lord]

Hi @Rakesh Prashanth ,

I completely agree with @Dave Mathijs. Adding defects and tasks in the middle of a sprint is an increase in scope and should be shown in the sprint burn-down chart as such.

To correct this increase in scope from high-priority work, teams will typically reduce scope by removing other planned work items from the sprint and bringing them back to the backlog. This should even things back out on your sprint burn-down chart.

Hope this helps!

Bryce