Remaining Values of burndown charts inaccurate after splitting an issue in a sprint that has started

Issue Summary

When an issue is split after a sprint has been started, the remaining values line shows the new issue resulting from the split as 'work added'. This results in an inaccurate representation of the remaining work in burndown reports. 

Steps to Reproduce

1. Set a Scrum board to use Story Points as the estimation statistic.
2. Add several stories to a sprint and estimate.
3. Start sprint.
4. Split one issue that has been estimated to 5 points- estimate the new one to 2 points, old one to 3.
5. View Sprint burn downchart.
6. View Release burndown chart.

Expected Results

Remaining values remains unchanged as the actual amount of remaining work is unchanged - or-  points are added as a scope change to the new issue and points are removed as a scope change to the old (and actual value remains unchanged).

Actual Results

The sprint burndown chart shows the new issue created from the split as a scope change and adds two story points to the graph.

The release burndown chart also shows inaccurate values for remaining work (3 has been subtracted as 'completed' work and 2 has been added): 

Notes

Remaining value is accurately reflected in the table below. See screenshot below. Note the table shows 16 points remaining vs the chart (screen shot above)which shows 18. A possible solution for this would be to first check if an issue was split from a parent and use the parent's creation date for the chart (so that the work is not counted as a scope change). 

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available