Time remaining for child issues gets added a second time for the parent to the sprint scope

[Sascha Sturm]

When adding Original Estimates or Time Remaining to child issues, the Time Remaining gets counted twice in the sprint scope: once for the individual child issues and once as the aggregate for the parent.

The Original estimates are not counted twice, only the time remaining.

It happens for all child issues and parent issues, not just for some.

We don't know how long this has been going on, but we have been puzzled by seemingly too big sprint scopes for a few months now.

We also got in contact with the support for Clockwork - the time tracking plugin that we use and they assured us that the issue is not on their side, but on Atlassian's.

Our current workaround is to add the aggregated Original Estimate to the parents only, while we track time on the child issues. Obviously not ideal but better than having to subtract the parent time remaining from the sprint time remaining for all the parents.

Does anyone have this issue as well?

[Bill Sheboy]

Hi @Sascha Sturm -- Welcome to the Atlassian Community!

Have you checked if you have any automation rules which may be adding the child issue values to the parent?

Kind regards,
Bill

[Sascha Sturm]

Hey @Bill Sheboy ,

We don't have any automation rules like that.
It's only the automatic roll-up from Jira (for which there are no settings anywhere).

Best regards,
Sascha

[Bill Sheboy]

Please check the change history for the parent issue as that may show what / who is adding the extra time.

[Sascha Sturm]

We don't have the issue history for Jira Plugin. The remaining estimates of the subtasks are correctly rolled up to the parent task, though (just in case I wasn't clear about that).
e.g. if the remaining estimates of all the subtasks sum up to 1w, then it also shows 1w time remaining in the parent, not 2w. The issue is that both the 1w from the subtasks as well as the 1w from the parent are added to the sprint scope.
Anyways, I'll get the 30 days free trial for the issue history plugin now, just in case...

[Bill Sheboy]

Issue history is not a plugin / marketplace application.  It is a built-in feature of Jira. 

Usually, the only time issue history does not show changes to the issue fields is when a marketplace addon (e.g., Clockwork) does not store its information as custom fields, but instead stores it elsewhere.

Please navigate to one of your parent issues, and examine the History tab near the bottom of the view.  Then look for any changes to the estimations to see any changes to the issue.

To understand how sprint scope and burn charts work when time tracking estimates are used, please review this documentation.  If it is not working as described, please ask the marketplace vendor how their application works relative to the built-in behavior.

https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-burndown-chart/#Understanding-the-Burndown-Chart

https://support.atlassian.com/jira-software-cloud/docs/estimate-an-issue/#Log-time-and-adjust-the-remaining-estimate

[Sascha Sturm]

Oh sorry. Thanks for the explanation.
For the child issues, it looks like it works as expected (No time has been logged on the child issue yet.

The parent's history does not show the changes in original estimate and time remaining of its child issue.


The original estimate and time remaining added to the child issue (both 1d 2h) get rolled up to the parent issue (originally both 1w 1d 4h, then 1w 2d 6h). This is expected behaviour, as far as I can tell.


By adding the 1d 2h original estimate (and since no work was logged also to the remaining time) to the child issue, the remaining time for the entire sprint (the scope) changed from 8w 3d 2h 19m


to 9w 6h 19m.


so it increased by 2d 4h, double the 1d 2h added to the subtask and rolled up to the parent. Interestingly, the original estimate is increased by 1d 2h, so the original estimate does not get doubled.

Do you need some more info?

Also, thank you very much for your time!

[Bill Sheboy]

I do not believe there is anything built into Jira features to sum child issue time tracking to update a parent Epic to the Epic time tracking.  That is why I asked about automation rules or other marketplace addons / apps.  For subtasks, and as shown in one of your images, there is a Jira checkbox to include subtask time in their parent story, task, or bug issue type for display purposes.

The images you show are truncated / cropped, and so the context and location within Jira is unclear. 

Those last two images appear to be from a marketplace addon / app and not from built-in Jira features.  If that is the case, please ask the marketplace vendor for support explaining the differences.  It is their app showing the difference because you have confirmed with the audit log there is no change to the parent issue.

[Sascha Sturm]

I can't find a page in the documentation that explains roll-ups from child to parent just on its own (not in relation to another topic), but here are some sources which make me think that it's a built-in Jira feature.
https://support.atlassian.com/jira-software-cloud/docs/roll-up-values-in-advanced-roadmaps/
https://support.atlassian.com/jira-software-cloud/docs/how-advanced-roadmaps-rolls-up-estimates/
https://support.atlassian.com/jira-software-cloud/docs/estimate-an-issue/#Why-not-estimate-on-subtasks-and-roll-that-up-for-Velocity-and-Commitment

The parent is a Story and the child issues are Subtasks (not Epic and Story/Task), but that should not make a difference.

Unchecking the checkbox to include subtask time is not remembered, so it does not resolve the issue. As you said it is just for display purposes.

To give context to the last 2 images:
Here I am in the Backlog of our Scrum Project. We do not use story points for estimation but time estimates with the Original estimate - This might have been a source of confusion. We estimate issues when we take them into an active sprint. Before that, they have no estimation assigned to them.
As you can see, the active sprint is Sprint 24.9

When I click on the ..., the "Workload by Assignee" modal opens. 

I could not find any mention of this in the Jira documentation. Though, it would be illogical to give Jira users the option to select "Original Time Estimate" as the estimation method in the board configuration and then NOT have some built-in way to see the aggregated estimates for all issues in the sprint. If that was the case, then everyone who uses Original Time Estimates for estimation would need an extra Marketplace plugin or calculate the sprint scope by hand...


If this should indeed not be a built-in Jira feature, then it is most likely a feature of the Clockwork plugin. Any other plugin that we have wouldn't make a lot of sense...
I have already contacted the Clockwork support and they have assured me that the issue is not caused by them.

[Sascha Sturm]

Just in case: We have some tickets from the last sprint that we have started but not finished yet taken over into this sprint (which is why the original estimate of the entire sprint in the modal is much bigger than the Time Remaining of the entire sprint)

[Bill Sheboy]

Thank you for clarifying with those images!  Those appear to be from the built-in, time-based estimation and not the addon.

And...you appear to be on the Free license level.  Some of those documentation pages you reviewed are for the Advanced Roadmaps feature, which is for Jira Premium, and above, licenses.  It is not part of the Free license level features.

That time tracking information appears to roll up the data just-in-time of the showing the "workload by assignee".  If you are adding both an Original Estimate and Remaining Estimate to an issue using logging, I would expect those values to be summed and added to the total Original Estimate.  (Although, I would not expect a team to change the Original Estimate of an issue to change once planning has completed and the sprint has started.)

I did find an open defect for a company-managed project, Kanban board and this "workload by assignee" when using subtask, but it shows not counting all of the data (rather than duplicating any of it).  I did not find any for double counting with Scrum boards / backlogs.

If you can narrow down the steps to reproduce the symptom, that may help Atlassian to offer suggestions.

[Sascha Sturm]

Yes, we do have a free license level.

Just in case this should have something to do with it (although I doubt that it has) ...

The way how we usually go about adding Original estimates, work logs and Time remaining is the following:

1. Add Original estimate at beginning of sprint
--> No work logged yet, so the remaining time estimate is calculated automatically as [Original Estimate] - [Work logged] = [Remaining time]

2. During the sprint, work is logged on tickets by the Clockwork plugin: Every time an issue moves into "In progress", a timer is started. Every time an issue moves out of "In progress", the time that it was in there gets automatically added as a work log.
--> The time remaining is again calculated by the formula above

3. If an issue in this sprint is not finished by the end of this sprint, it gets re-estimated and moved to the next sprint. In the re-estimation, we estimate the Time remaining, so this time the Original estimate gets updated automatically as 
[work logged] + [Time remaining] = [Original estimate]

Regarding the "narrowing down the steps to reproduce":
Do you have any unanswered questions? From my side, I have given all of the info that seems relevant to me. As we are on a free plan, we cannot even report a bug to Atlassian. No one I talked to so far could replicate it, so I must assume that it is somehow account-specific...

[Wojciech Wardaszko]

Hi Sascha,

I strongly advise against sharing your login details with anyone. This includes API tokens.

When you file a ticket with Atlassian, their tech rep may ask you for permission to access your instance. Once they get your approval, they can log into your Jira without asking for your login credentials. If anyone asks you for credentials, they are a bad actor.

As for the issue itself, we were able to reproduce it. The steps were:

1. Create/add an issue to the current sprint

2. Set the original estimate on it. The time remaining is automatically set.

3. Create a subtask for that issue.

4. Set the original estimate on it. The time remaining is automatically set.

5. Alter the original estimate on the subtask to a smaller number. The time remaining is automatically set to the same value, which is correct and expected.

After these operations, the workload by assignee view returns incorrect values for time remaining - as if it did not get updated.

In the screenshot above, only 30 minutes were tracked by the last assignee.

I hope this helps to pinpoint the issue.

Cheers!

[Sascha Sturm]

Thank you Wojciech,

I'll try and avoid this when estimating for the next sprint then.
It seems like I cannot report a bug to Atlassian, as we are on a free license.