Time Remaining Incorrect in Greenhopper

[Alan elfert]

I am using JIRA 5.0.4 and Greenhopper 5.9.6. We are experiencing issues with the Time Remaining summary in Greenhopper. I have a case open with Atlassian.

I am being told by Atlassian that the reason this is occuring is because we edit the time remaining for issues. They are saying we should not edit that. THey are also saying that Greenhopper calculates the time remaining as original estimate - time spent.

Am I missing something? I thought the whole purpose of the time remaining field is to allow users to change it when they find out the work remaining is different than the original estimate - time spent.

Thanks.

[Alan elfert · Accepted solution]

Once I escalated this issue within Atlassian they agreed that I should be able to change time remaining on issues and the time remaining on the Agile boards should be correct. They analyzed our data and determined that the issue was I had a post function that was updating time remaining on closed issues to zero and that post function was after the history post function. I moved my post function above the history one.

I still do see that my time remaining is not always exact on sprints but don't know what the root cause is now because it hasn't been off enough to take the time to report the issue, send our data off, etc.

[Daniel Vigovszky]

We also have this problem. If an issue is completed in 30 minutes instead of the originally estimated 1 hour, and its remaining time is set automatically to 0 by the workflow, then the remaining time on the burndown chart is only decreased by 30 minutes instead of 60. Is this intentional or a bug?

[boardtc]

Were you able to get past this issue?

One thing to keep in mind is the remaining time when an issue is closed.

We have set up a post function so that when an issue is closed (moved to done) the time remaining is automatically set to zero. Prior to this, unless the time remaing was manually set to zero or the logged work matched then this remaing time would show in the hours burndown chart.

[Alan elfert]

Yes. Once I escalated this issue within Atlassian they agreed that I should be able to change time remaining on issues and the time remaining on the Agile boards should be correct. They analyzed our data and determined that the issue was I had a post function that was updating time remaining on closed issues to zero and that post function was after the history post function. I moved my post function above the history one.

I still do see that my time remaining is not always exact on sprints but don't know what the root cause is now because it hasn't been off enough to take the time to report the issue, send our data off, etc.