Time Remaining Incorrect in Greenhopper

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.

3 answers

1 accepted

1 vote
Accepted answer

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.

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.

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.

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?

Suggest an answer

Log in or Sign up to answer
Community showcase
Published 2 hours ago in Jira Ops

Jira Ops Early Access Program Update #5: Three new ways to get a live Jira Ops demo!

Welcome to your weekly Jira Ops Early Access program update, where we’re sharing news and updates on Jira Ops progress as we work toward our 1.0 release. If you ever want to drop us feedback or ideas...

13 views 0 0
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you