Why does my sprint burndown chart total story points change?

Question

Hi, so I am using Jira for a school project, and I noticed how the total story points (y-intercept on the chart) on the sprint burndown chart change. For example, if I started the sprint with 120 story points, and then some of my team members change issues, the total story points reduce to 80 story points.

I am thinking that this happens because some of the original issues were deleted and replaced with new ones, so original story points were reduced? This is really annoying because what if there are some changes throughout the sprint? I know that I shouldn't try to change too many issues once a sprint starts, but what if we need to? Is there no way for the y-intercept (total story points) on the chart to count the cumulative story points over the sprint, instead of counting only the story points of the initial issues?

Or if I am just doing this whole thing wrong, please let me know as well. Thank you

Nic Brough -Adaptavist- · Answer

Why are you deleting and replacing issues during the sprint ? (or even at all - it's simply bad practice to delete Jira issues).   You're destroying your sprint data.

Once a sprint is started, yes, your deletion is going to prompt it to record scope change.

Bill Sheboy · Answer

Hi @Phillip La -- Welcome to the Atlassian Community!

If I understand your question correctly, you appear to be asking if the maximum (leftmost starting point) value for the burn chart should change after the start of the sprint...that is, after sprint planning completes.

That would hide valuable information: something happened since sprint planning which has altered the plan.  Changing the burn chart starting point seems to be re-defining history and hiding the potential to learn something:

* why are we changing many issues after planning for the sprint
* what did we not know in refining the issues
* what unplanned work did we not anticipate
* what could we do better to improve our planning and refinement
* etc.

In my opinion there are many challenges with the built-in Jira burn charts and they work okay for very basic use cases.  They are not as valuable for most teams, real-world use cases.  For the scenario you describe they seem accurate, although unforgiving when there are usage errors (e.g. starting a sprint too soon/late).

Kind regards,
Bill