Same happened with me. How to fix this misytpe issue.

I've got to add my say here also. I recently added BigGantt to my JIRA instance. I was trying to accommodate a customers need to have accurate time frames for Epics. We tried to retrospectively change the epics to have start and end dates. This turned into a massive debacle with every single issue card receiving estimations based on the epic delivery date they were attributed to.

Sprint velocity is ruined, despite me removing the addon and removing each remaining time estimate from all issue cards. The inability to fix this sprint means I can not showcase our teams effort in delivering more accurately with estimates. See attached screen shot of the sprint burndown, pretty useless state of affairs.

We are clearly *_not _*talking about "allow[ing] users to do this", but about allowing _*somebody *_to fix errors.

We have the same issue and I also hope that this will get reconsidered. As Andreas said, an unfortunate typo eventually (and inevitably) happens. And when it does, critical velocity metrics/ reporting tools that Jira provides become useless for the rest of the sprint.

+1!

+1!

I would like to voice my opinion in the hope that this may be reconsidered. This just happened in the project I'm working in, and it makes the charts downright useless...

We have decided that we would not pursue this issue. We feel that what is being asked of the product here is the rewriting of JIRA's issues change history. It is our belief that we should not allow users to do this. To introduce additional functionality to work around the change history would complicate the product for other users.

To answer this; I agree having any developer changing past history all willy-nilly might not always be a good idea from a project manager stand-point, but please consider allowing managers or project owners to do it when an unfortunate typo eventually (and inevitably) will happen.

One could actually say that as it currently is, Jira allows all project participants who are allowed to add issues to a sprint, to irrevocably ruin the reports (Taking a full backups and turning off Jira for all of my organization just to fix a single project's report would probably be sneezed at by our IT department, and is not a viable solution IMO).

Hey All,

There is a suggestion that might help to lower down the impact of the mistype in BurnDown Charts:

• https://jira.atlassian.com/browse/GHS-11504

To have the ability to zoom in the specific region, please vote on it if you found it useful.

For those who might have accidentally input the estimate using comma as decimal, you can vote on this issue instead:

• https://jira.atlassian.com/browse/JRA-30128

Cheers

Many thanks to everyone for voting and commenting on this issue.

We have decided that we would not pursue this issue. We feel that what is being asked of the product here is the rewriting of JIRA's issues change history. It is our belief that we should not allow users to do this. To introduce additional functionality to work around the change history would complicate the product for other users.

We hope you understand this position.

Many regards,
JIRA Agile Team

I have no experience making typos in the original time estimate, but in case of remaining estimate, making a typo is lethal. I can't see why this is so hard to fix.