Thanks Alex.

In the meantime I will definitely look up the carry on feature.

Also, I figured out what was causing this issue and was able to correct it, which is not the right way to do it but it seemed to be the only solution.

The tasks that had the remaining values in the excel export, even though in the sub task it was 0, were on those sub tasks that were completed in previous iterations but migrated to the current iteration.

When I originally back dated the worklog to the date it was closed in the prior iteration. The current iteration didn't seem to recognize this.

To fix this:
1) I reopened all the sub-tasks that had the issue where remaining time was showing up in the excel report.
2) I had to edit the last work log, change the date to today's date or another date in the current iteration and kept the remaining time to 0.
3) Closed the sub tasks.

Once this was completed, the chart board was properly reflecting that these issues were closed with no additional time remaining.

Even though this is a work around for it, it shouldn't be doing it this way. Even if the sub task was zero'd in the previous iteration, it should just re-adjust how many hours to calculate for the current iteration and still show a proper burn down.

Hi,

we've been working on some bugfixes and improved transparency for the hour burndown calculation and Excel export, these are part of GreenHopper 5.4 (please see http://jira.atlassian.com/browse/GHS-2670 for a summary).

When it comes to moving issues over to the next sprint, it's important to release the version through GreenHopper and using the "carry on" feature to migrate the issues that are not done. This way, GreenHopper stores the information that these issues have once been part of the released sprint and can include them still in the timetracking calculation.

Cheers,
Alex

I have the same issue as Brett above. We moved a number of our user stories and their sub tasks from one iteration to the next, because we underestimated our work and a number of bugs were found that could not be completed in the prior iteration. All sub tasks that were completed in the last iteration, were still carried over as they related to the user story that was not complete. So for some of the sub tasks in the current iteration, all work was logged prior to the start of the current iteration. When I look at the task board for the current iteration, all the completed issues have a 0 for time remaining. When I got to the chart board it still shows that these issues are not complete and that there is remaining work on the issue.

One example is:
Sub Task 41 was originally in Iteration 6 with an estimate of 3 days to complete, but actually took 1d 4h to complete in Iteration 6, ending Dec 1st.
The user story that the sub task was linked to was not fully completed by the end of iteration 6, so all sub tasks (including 41) were migrated to Iteration 7.
Looking at Iteration 7 chart board, all the closed issues have 0 remaining estimate but when I filter by 'Closed' I see that there are 65 hours remaining. When I export the Chart Data to excel... it shows 12 hrs remaining for issue 41 on December 9th, even though on the Planning Board and Task Board it shows 0.

Please advise.

I'm using GreenHopper 5.3 and have found really strange behaviour for the hour burndown not recognising entries for a given day, admittedly, these worklogs were back-date created.

How do I correct this? It's throwing the trend way out as the remaining hours is not correct. If I extract the chart data (Cogwheel > "Excel (Chard Data)") there are many entries with -1, some with 8, all closed and no remaining work hours for each of these issues.

Can a SQL statement be created to recalculate? If so could a service be created to perform nightly rebuilds of incorrect hours?

The logic behind the Hour Burndown Chart computation has been adjusted to deal with the various ways worklog related data can be entered in JIRA in the best possible ways. Please refer to the GreenHopper 5.2 release notes, a detailed documentation will be linked from there.

It is bad news isn't it? I had my Team Effort go down over 2 days. There is no way of fixing it without changing the database a far as I can tell. This is because the worklogs can get amended and deleted which all the changes to the Remaining Estimate remain in the issue history.

However, the good news is that the current remaining estimate is always correct so the end of the graph is accurate even if the history has become distorted.

this is a bummer, any recommendation once it has happened to get the burn down looking normal again?

Hello JC,

Many thanks for the quick response.

Yes, I have removed Worklog deletion permission and that is an acceptable workaround.

Cheers,
Tadhg

Hi Tadhg,

I was able to reproduce this behavior.
Setting the original estimate twice is mixing GreenHopper up.

You have spotted the problem with the worklogs deletion.
JIRA will reset its issues that have "no more" worklogs and let users re-change the original estimates. It just wont care of what was done in the past for these issues ...

This scenario is rather difficult for GreenHopper to avoid unfortunately. The best way to avoid it would be to not grant users with the worklog deletion permission. I know, this is certainly not a long term solution.

I have reported this to the JIRA team, they should be revamping the timtracking of JIRA in a very near release. I will make sure this is answered. In the meantime I will make sure it is documented.

Thanks a lot for reporting this to us Tadhg, it was greatly appreciated.

Cheers,
JC