Original Estimate on parent issue

[Baylor Peak]

Hello all,

Is there a function or feature that will automatically sum up the Original Estimate fields for sub tasks into the Original Estimate field in the parent task?

For instance, I have 5 sub tasks underneath a task that I have assigned 1 hour to each sub task. My parent task is just a container and I just want all the times of the sub tasks to populate the Original Estimate on the parent task.

[Mykenna Cepek · Accepted solution]

Automation in Jira (Cloud) recently added some subtask-spanning math functions that solve these sorts of problems:

• https://community.atlassian.com/t5/Automation-articles/How-to-sum-up-logged-hours-using-automation-in-Jira-Cloud/ba-p/1409115
• https://www.atlassian.com/software/jira/automation-template-library/sum-up-story-points

[Baylor Peak]

But we are not logging time. we are just entering in Original Estimate.

[Mykenna Cepek]

Bullet 2 in the first link talks about "Sum up remaining estimates or original estimates in all subtasks and set it to the parent task." Sounds like that's what you want to do.

The second link illustrates how to aggregate subtask data into a parent Story (using Story points, but it's the same process).

What you want to do is create a Jira Automation rule which:

• Triggers on a change to the "Original estimate" field
• Uses a conditional to only proceed if the triggered issue is a Subtask
• Branch to the "Parent" (Story)
• Set the Story "Original Estimate" field to the SmartValue {{issue.subtasks.Original Estimate.sum}}

Thus, when any Subtask is edited to change an Original Estimate, the parent Story will get updated to reflect the new total.

[Baylor Peak]

Yes, that is what I was working towards, but "Original Estimate" field is not available in the dropdown for Field value changed

[Mykenna Cepek]

Ugh. I assumed that field would be available in that trigger.

Ok, so it took some experimentation and sleuthing, but I think I found a solution.

Start your rule out with this trigger and include this additional conditional early:

I saw some notes that "timeoriginalestimate" might also be relevant for the conditional. You can use the "Audit Log" action to output the {{fieldchange.field}} value and confirm what comes through when you change the field of interest in your Jira instance.

You'll still want the remainder of what I previously outlined:

• Uses a conditional to only proceed if the triggered issue is a Subtask
• Branch to the "Parent" (Story)
• Set the Story "Original Estimate" field to the SmartValue {{issue.subtasks.Original Estimate.sum}}

For others playing along at home, I discovered that the {{fieldChange}} smart value is NOT set when using the "Issue updated" trigger. Grrrr.

[Baylor Peak]

Does this look right?:)

So what is happening when this rule is triggered, it is summing all subtasks in my project....

My test Parent is set to 0m for Original Estimate

Then I have 3 sub tasks each

Now, my Parent task is displaying 13w 2d 4h

[Mykenna Cepek]

Not quite. For this bullet:

• Branch to the "Parent" (Story)

you'd want to use the following (instead of your "For Sub-tasks" branch):

Also, don't forget about this bullet point:

• Use a conditional to only proceed if the triggered issue is a Subtask

That should be before the branch. This is because you only want to fall into this branch when the triggered issue is a Subtask.

[Baylor Peak]

Sorry, this is the part that I'm not getting. I understand the IF logic (IF sub task exist for Parent) but I am confused how to configure it in this system :) :(

[Mykenna Cepek]

Wow. This was not as trivial as it look originally. I built out a working rule, which looks like this:

But as the thread above shows, the trigger and initial conditional wasn't originally obvious. One last bit of surprise was how the "Edit issue" action needed to be configured:

Note the division by 60, and especially the suffix "m" for minutes.

Internally, Jira stores duration values in seconds. So, we divide by 60 to get minutes, or divide by 3600 to get hours.

Why not just divide by 3600 here and drop the "m"? I tried that first, and the division result was rounded (giving me 8h instead of the expected 8.3h, for example). The documentation doesn't explain this; I might report it as a bug.

The above is tested and works. Hopefully you can find success with it, @Baylor Peak 

[Mykenna Cepek]

Note: the above solution assumes your Jira instance is set to use HOURS as the time tracking default unit:

You can check this for your Jira instance (even without Admin privs) using this REST call:

https://YOURINSTANCE.atlassian.net/secure/admin/TimeTrackingAdmin.jspa

(substitute your instance prefix)

If not, adjust the math accordingly.

[Baylor Peak]

OK, all that worked :)

One last thing...is there a way for the subtasks sum to be ADDED to whatever is in the Original Estimate on the Parent task?

So, if I have a Parent task that has 2h for that task but then I have a testing sub task of 1h. Is there a way for it to add that 1h to the Parent or is it all or nothing, meaning I can only have the Original Estimate reflect the totals of subtasks?

[Mykenna Cepek]

So the only way to manage that is to create a new custom field for the Stories, which is going to complicate things in a number of ways.

I'm assuming you want to be able to revise the Original Estimate value for the Parent Story/Task itself. In that case, you can't use the same Original Estimate field to also hold the total including the Subtasks.

If the above assumption is not correct, please clarify where I have it wrong. If that assumption is correct...

You have two options for this new field:

1. New field is named something like "Original Estimate Total" and automation maintains it as the total of the Story/Task "Original Estimate" field plus all the Subtasks; or
2. New field is named something like "Story/Task Original Estimate" which is for the Original Estimate of the Story/Task only, and automation puts the total in the "Original Estimate" field.

I like option 1, as it maintains consistency of what the "Original Estimate" field is across all issue types. It also simplifies the automation rule a bit.

Proceeding with all these assumptions, the rule needs the following changes:

• We need to process Subtasks separately from Story/Task level issues. Why? Two reasons: 1) It turns out that Subtasks show "timeestimate" for {{fieldChange.field}}, whereas Story/Task level issues show "timeoriginalestimate" (likely an ancient Jira anachronism); and 2) The rule logic for accessing the "parent" issue is different in the two scenarios.
• Revise the computation to return a result in fractional hours, rather than integral minutes. Previously the "m" suffix permitted a value in minutes, but that was when we were storing the result in the Original Estimate field (which is a special Time Tracking field). A bare "Numeric field" custom field needs to instead store fractional hours, which will show for example as "12.5" rather than "12.5h".
• Store the total in a different field in the parent issue.

Here's the new computation of the total:

{{#=}}{{issue.subtasks.Original Estimate.sum.plus(issue.Original Estimate)}} / 3600 {{/}}

Note that I've changed this to using a computation {{#=}} total / 3600 {{/}} rather than using the .divide(3600) function. It looks like the function rounds, which I believe is a bug in automation. I'll report that shortly.

Note also that the denominator changed from 60 to 3600. This is to convert minutes to hours.

Here's what the new rule looks like. Note that some of the conditionals have been aggregated for simplicity:

For the two "Edit issue" actions, use the new computation value listed above.

Note that this rule will fire for every issue edit in the configured project(s), but will only update the parent issue when the Original Estimate field changes. Keep an eye on the Usage section of Automation, if your Jira plan has monthly rule execution limits.

[Baylor Peak]

I think we are OK there for usage since we only use rules for single projects and not rules that affect multiple projects if I read this correctly.

What doesn’t count towards my usage?

Single-project rule executions do not count towards your usage. A single-project rule is a rule that automates a task or process that only affects one project.

Also, I discovered our instance is using minutes instead of hours, but our team also round to the hour so we never enter Original Estimate with minute increments. Does that change anything you suggested?

So, lastly, if I create this new custom field for "Original Estimate Total", is this going to mess with my Burndown chart? We don't use Story points nor do we log work time. We solely utilize Original Estimate and then the burn down tracks our progress based on items moved to done throughout the course of the Sprint.

Also, if I have not said it yes, thank you so much for all your effort in this:0 I am also a Salesforce Admin as well as Developer but that is a cakewalk vs this Jira stuff ;) I wish I could just write my own custom trigger :)

[Mykenna Cepek]

Using rules configured for single projects will avoid the monthly execution limits, yes.

I believe the "Default unit for time tracking" only impacts how a bare number like 15 will be interpreted in a Time Tracking field. In my instance it will be 15h, in your instance it will be 15m. The internal storage of that data is still converted by Jira to seconds, so I think all the math above works as shown.

The proposed new field will not impact your Burndown chart at all. Continuing to use the "Original Estimate" field as normally used natively in Jira should keep your reports and metrics consistent and unchanged.

The new field will just provide visibility to the aggregate Original Estimate values at the Story-level, which seems like the original goal.

[Baylor Peak]

So all this has brought a question to mind that I have been unable to find a definitive answer.

Say I did nothing, no rules, just base Jira. What does Jira do natively on a Scrum board regarding sub-tasks? Meaning, if I have a parent task that has 4 hours for the Parent task and then 2 sub tasks each 1 hour, is Jira already calculating the sub tasks for the overall length of the Sprint, or is it only looking at what is in the Parent Original Estimate field?

[Mykenna Cepek]

So there are some places where Jira aggregates things like this, but it's not as universal and complete as we might wish for.

You've discovered, for example, that Original Estimate values in Subtasks aren't natively aggregated relative to their parent Story or Task in a visible way in issues.

If you are using the native Jira Time Tracking (not an add-on App like Tempo Timesheets), then at the Story/Task level the "Time Tracking" field does show an aggregate that includes subtasks. But that's not a real field, it's a visualization.

Values like Time Remaining are also internally aggregated in a way that provide value in a Burndown chart.

When issue searches, there are these three fields available which make aggregated data visible, but they are computed/internal value, not editable fields:

You'll probably find that many of the built-in reports (burnup, burndown, sprint report, epic report, etc) will aggregate the estimates as you expect.

The lack of visibility to some of that data at the issue level is sometimes confusing.

[Bianca Ruiz Fialho]

Hello @Mykenna Cepek

I'm looking all over for this solution (sum subtasks original estimates into parent's original estimate field) 
I've tried the exact same automatin you suggested above, even changed the default unit for timetracking to make sure all would work the same way...
Well, the parent's original estimate field keeps getting updated with the value 0.

I even added an action of commenting the issue with {{issue.subtasks.Original Estimate.sum.divide(60)}}m, and that only confirms it keeps adding 0 to the original estimate.
Do you have any idea why this might be happening? 

[Mykenna Cepek]

Hmm, hard to say for sure with just this information.

Some things to try to discover more about what's happening:

• Check the Audit Log for this rule to see if there are errors.
• Ensure you have non-zero Original Estimates on the subtasks under the parent issue you are testing.
• Use "Log Action" liberally in your rule to output (in the audit log for the rule) information like: what issue triggered the rule (output the issue.key), what the Original Estimate value is for that subtask, what the issue parent (in the branch) is, what the parent's Original Estimate started out as, what it ended up as, etc.
• Inspect the history on the subtask and parent issues being tested. Look to see if any other automation rules might have triggered on those issues and interfered with this rule.
• Eliminate the divide() and inspect the raw Original Estimate value - just be aware that it will be in seconds. This can help uncover hours vs minutes problems (e.g. dividing by too much can result in zero results).

Hope that helps you figure it out!

[Monica Morris]

I'll add to the chorus of grateful people and say thank you @Mykenna Cepek!

I was having trouble with this exact use case and it turns out my automation wasn't working because I had 

{{issue.subtask.Original Estimate.sum.divide(60)}}m instead of 

{{issue.subtasks.Original Estimate.sum.divide(60)}}m

Such a small difference but without the 's' on the subtasks, the rule wouldn't run properly!

Very much appreciate you posting the successful rule.

[Matheus Thomé]

I spent many hours searching for this. It worked perfectly here. Thanks a lot @Mykenna Cepek You're phenomenal.

[Edmiel Leandro]

Thanks for this explaining @Mykenna Cepek 🤝