How to correct a story points typo on an open sprint?

[Andrew Schaedler]

While correcting a story point at an open sprint a typo happened.

Now it's messing up the burn-down graph because it's registered at the Issue History.

How do I fix that?

[Walter Buggenhout _ACA IT_ · Accepted solution]

Hi @Andrew Schaedler and welcome to the Community!

Just correct the story point estimate to whatever it should be and don't worry about your burndown chart. Your job as an agile team is to deliver working software and give value to your customers, not aiming for the perfect burndown chart.

If you need an explanation for what happened in your chart, add a comment to the retrospective report of your sprint so people know what happened there and move forward!

Hope this helps!

[Andrew Schaedler]

Hi Walter thanks for answering.

I'm playing as Scrum Master so I need to have the reports showing the data correct.

Right it has a huge spike and is hard to understand it due to the graph scale.

Since the spike was created from a typo I would like to correct it. 

Just to you have an idea. Our sprint has average of 400 point the typo is more then 600000. so doesn't make sense at all.

[Walter Buggenhout _ACA IT_]

Hi @Andrew Schaedler,

I understand this is a slightly awkward situation, but your job as scrum master should be to help your team work at the best of its ability and improve continuously, not making sure your reports are showing nicely.

Having said that, I have done quite a drastic experiment to see if a workaround is possible. And there actually is. Every update you perform to the estimates of your issues are tracked in the issue history. So if you increase or decrease the estimate of an issue, add or remove an issue to your sprint, that is all recorded in the issue history. But the history gets removed entirely when you physically delete the issue that had that history.

So what you could do is adjust the estimate of the broken issue to what it should be; clone the issue, delete the old issue that's in your sprint and add the cloned issue to your sprint instead. That will still show in your sprint issue as scope change, but the spike will be gone from your burndown chart. It would not be correct either, but you will have disguised the typo. 😉

Still, if it wasn't me, I would not do that effort. And I can imagine it may sound like a somewhat scary workaround, so you may try it in a test project with fake data first to validate it works as described (it does, I went through the different steps one by one). But one you may consider as an option if the chart is really important.

A few screenshots from my test. First: created a sprint and added an issue with a ridiculously high estimate.

Then updated the estimate to a much lower value, which then is reflected in the burndown chart and the history table below. The very high estimate is still in the chart:

Then I deleted the issue, bringing the chart down to normal proportions and erasing everything from the issue history:

[Andrew Schaedler]

Thanks, Walter that worked.

[Trudy Claspill]

Clever work around, @Walter Buggenhout _ACA IT_ ,though it does wipe out all the other issue history and comments, and could require recreating link relationships if the original had those also.

[Trudy Claspill]

That would require a method for changing or deleting change history for the issue and/or sprint, and I'm 90% sure there is no supported UI or API method for doing that in Cloud. And since we don't have direct access to the database in Cloud, you can't use a database hack to correct it.

Since you are on a paid plan you could ask your Jira Administrators to open a support ticket with Atlassian to see if they might be able/willing to make a change in the back end to help you with this.

https://support.atlassian.com/contact/#/

[Andrew Schaedler]

Thanks!