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

Question

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.

Ronny Hanssen2 · Answer

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

sclowes · Answer

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.

Thanks,
Shaun