Splitting an estimated issue destroys burndown and velocity

For example we had one huge user story with 13 points. Let’s call it “Story A -> 13 points”. We made following changes:

• Grooming was performed and decision was to create a two smaller stories.
• The “Story A” was renamed and it’s estimation was reduced to 5 points.
• We created a “Story B” with 5 points for example.
• The scope was much smaller than we thought before, so now we have 10 points in summary instead of 13.
• What Jira has done with charts -> disaster!

JIRA charts -> Jira project baseline was reduced by 8points (the middle part of each bar in project burn down chart) and a new scope has appeared - > 5points added in the bottom of current sprint bar. It shouldn’t be done in this way. We should have option to mark that this new item was based on previously generated “mother” story. The proper behavior should be different -> the baseline should be reduced by 3 points and this new groomed story should be treated as a part of baseline.

The other much worse situation is when you decide to delete old story and create a two new stories instead, then these 13 points from baseline disappear.

Is there any workaround to fix this? Somehow edit the original baseline content? Or some other way of splitting issues?

Best Regards

Per Olofsson