My backlog is separated into versions. One version has subversions (sprints as well). For a sprint, the 'time remaining' sum statistic is correct, i.e. if I add time remaining for each story manually, I get the same figure.
This is not the case for the parent version however. It gives a 'time remaining' sum number which is way larger than what I get if I add remaining times per issue manually. I can't understand why it does it. I've checked:
Anyone had the same problem?
All issues In Progress are in current Sprint. But, as I mentioned, the statistics for current Sprint are correct. It is Release statistics (current Sprint is under this Release) that are incorrect. When I add up manually remaining duration for all visible issues under the Release, it's less (by more than 30%) than what the statistics show me. So it's as if the statistics add remaining time from issues I can't even see...
You might be facing a situation where some logged time are ignored by GreenHopper based on below:
"Sprint periods usually occur back to back. However, it is possible for time gaps to occur between them. If work is logged outside the time period of any sprint, but during a valid date within the time period of its parent version, then that work log will be ignored in the parent version's aggregate hour burndown chart."
Thanks for pointing this potential explanation to me. And although this is not what caused me the discrepancy :), it did indeed put me on track to finding the real issue.
When you release a version (say, a Sprint), unfinished work is carried over to the next Sprint (if you select that, which I did). But GreenHopper, however, freezes the chart for this released version that shows those remaining hours that were not burnt down in the Sprint. It appears that the difference between the number I get from statistics and the one I derive manually is exactly the sum of that unfinished work from released Sprints.
There, since we know the problem, any ideas how to correct this? Because I need the actual remaining effort, both in the statistics column as well as on the Release (parent version) burndown chart.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Meet @Dinesh Dhinakaran, @Vishnu Vasudeva, @Rajeev Verma, and Jamshid Nalakath: Our extraordinary AUG leaders from Bengaluru, India. These four work together to strengthen the bonds of their local co...
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!
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