Why does greenhopper subtract logged work from original estimate instead of using remaining estimate field?

My JIRA is configured in a way that when issue is resolved faster than it was originally expected (for example, 2h instead of 8h), remaining estimate is automatically set to 0h. But greenhopper does not take into account value of 'remaining estimate' field. It takes difference of 'original estimate' and 'logged work' instead. In the course of the sprint those inconsistencies (8h - 2h = 6h) pile up and at the end of the sprint burndown chart shows that there is still work to be done even though many tasks were completed faster. For example, if three tasks were completed faster then it was originally estimated (3h instead of 7h, 2h instead of 8h and 5h instead of 10h), greenhopper will consider 15h (4h + 6h + 5h) to be remaining estimate at the end of the sprint. Thus, GreenHopper breaks many burndown charts of my team and it causes different kinds of other inconsistencies.

Is this a bug or expected behavior? How would you recommend to configure JIRA and GreenHopper in order to get rid of this nasty problem?

PS. Currently installed GreenHopper version is 6.1.5.

2 answers

GreenHopper shouldn't do this. Are you using the new boards or the classic boards? The only case I can think of where this would happen is if your workflow post function to set remaining estimate to 0 happens after the workflow post function to write issue history. In that case the issue history does not correctly show an update of the remaining estimate so GreenHopper cannot work out how/when that change occured.


We are experiencing the very same thing. It is driving me nuts. I am nagging everyone on updating the remaining value on their issues, since that is the most likely time remaining. But, when the greenhopper charts keep using the original time estimate it is really not much help. The estimated completions anything but accurate.

Board Estimation ise set like this:

  • Estimation Statistic = Original Time Estimate (although we are planning to change to story points)
  • Time Tracking = Remaining Estimate and Time Spent

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

573 views 0 6
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