@zchaudhary, @webcontrol, @simon.fox: I think resolved issues are no longer monitored as closely as active ones. Maybe it would be better if you created a new issue describing the problem and commented here with the new issue URL.

Hi Atlassian,

we decided to use Jira Agile on your Cloud a few weeks ago. Now we faced with exacly this bug and tried to resolve it removing bad entered times inside the issue. As it is not possible to fix this on Jira Agile - we must think if Jira fits best for us. We were strongly surprised that you decided to not fix this bug but it is a blocker for the customer on Jira Agile Cloud platform.

Because we entered a value which lead to peak of the chart is too high (months instead of minutes) the Burndown for the whole sprint is not usable anymore. We are not able to see where we are.

So please think again if this bug has no value as the applications behavior is not as required and customers have no workaround.

Best Regards,
Jan

Is there a way to remove the spikes on an OnDemand instance if we don't have a database?

Do you really consider this an acceptable resolution? I am using OnDemand so removing database entries isn't an option (that I'm aware of).

It would at least be a step in the right direction if the user was warned that they are logging work that has a duration that exceeds the issue estimate by such a large amount.

Thanks for being understanding!

Peter, thanks for the info. While I could imagine JIRA Agile reacting on "RTE Change" history entries (and merging those with the actual work log changed history entries), I can understand that this might be a lot of work. Now if only I could disable the default unit of time in my project's work log entry dialogs

Hi Fabian,

We decided not to change this because there is a way to correct truly erroneous data outside of the UI, and because JIRA Agile is simply a consumer of the historical changes provided by JIRA itself. If there were ever to be a change, it would be within JIRA, not JIRA Agile. While you did change your work logs, you did not in fact correct the original transaction, which in JIRA's eyes is still valid - your change was simply another transaction recorded by JIRA, which is why the original spike remains. The only thing that JIRA Agile does here is gather all transactions from JIRA over time, and plots them. For each point in time, each transaction was the valid state of the issue.

Hope that helps and thanks,

Hi Peter,

Thanks for answering. Could you explain why you won't fix this? Manually erasing the spikes via the database is possible, of course, but not something we want to do all the time. After all, we do correct the work log entries via the JIRA UI?

Best regards,
Fabian

Hi Fabian,

We won't be fixing this, as this erroneous data can be removed from the database if required. If assistance is needed doing this, you can raise a ticket at support.atlassian.com, however this should be straight-forward enough to not require their assistance.

Thanks,

See also https://answers.atlassian.com/questions/215830/burndown-chart-how-do-i-remove-an-invalid-remaining-estimate-data-point.