Burndown chart: How do I remove an invalid "remaining estimate" data point?

[Fabian Schmied]

We're using Greenhopper 6.1.6 with a Scrum board. It often happens to us that someone logs work and makes a huge mistake - e.g., logging days instead of hours (because the default time unit seems to be days). When correcting the mistake, the remaining estimate is not fixed in the burn-down chart.

Here's an example:

And here's the culprit:

These spikes can get so high that the rest of the burndown is no longer readable:

What can we do to get rid of such spikes?

[Ivar · Accepted solution]

I would raise an support ticket with Atlassian on this. If the report isn't updated, it sounds like a possible bug.

[Fabian Schmied]

I did report it as a bug: https://jira.atlassian.com/browse/GHS-9862. Unfortunately, it's not going to be fixed.

[Esther turner]

Hi, Worklog entries are editable, but you have to be given permission. Check out the very bottom of the Project Permissions page and you'll be able to see who has access to what related to Time Tracking, for ex: http://screencast.com/t/Ch7ktOZDU. Hope that helps!

[Ivar]

I believe that this part of the question indicates that this is already done?

When correcting the mistake, the remaining estimate is not fixed in the burn-down chart.

[Fabian Schmied]

Yes, the worklog entry is already fixed. (See also the second line in the table above - the RTE change is caused by the worklog entry being edited.)