Statistics time remaining sum differs from that calculated manually (planning board)

Arthur April 18, 2012

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:

  • All assets in the parent version, which automatically includes all child version issues as well
  • I've even checked done issues (no time remaining there)
  • All versions (child and parent) have propper start and end dates assigned to them

Anyone had the same problem?

3 answers

0 votes
Fahd
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 19, 2012

Hi Arthur,

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."

http://confluence.atlassian.com/display/GH/Aggregate+Hour+Burndown+Charts

Arthur April 19, 2012

Hi Fahd,

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.

0 votes
Arthur April 19, 2012

Anybody had a similar issues? Possible reasons for this?

0 votes
Jakub Pierzchała
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 19, 2012

Hi Arthur

Can you check the Task Board view to check that the issues In Progress are the ones that increase the overall time?

Jakub Pierzchała
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 19, 2012

How about if you compare Time Remaining for current sprint with the Time Tracking report?

Arthur April 19, 2012

Hi Jakub,

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...

Suggest an answer

Log in or Sign up to answer