Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Sum Up Original Estimations - Jira Automation

So I currently had to build a lot of workarounds to get the sum of all original estimations into the Epic. But it can lead to errors, when I clone a task and add it into another epic (it is an edge case, I know, but I still want to fix this :D) Is there an easy way of doing this?

Something like:

"{{#=}}{{lookupIssues.original estimate.sum}} / 60{{/}}"


"{{#=}}{{issue.subtasks.Original Estimate.sum}} / 60{{/}}"

for Epics too? 

It is working for stories with sub-tasks, but not for Epics. 


Best Regards



2 answers

1 vote
Mykenna Cepek Community Leader Feb 18, 2021

Hi Dennis. Sorry to disappoint, but the short answer for you is this: you'll need to pay for a Jira add-on to do this.

The basic set of JQL and Automation features in Jira (even for the Premium plan you have) do not support the aggregation of data from Stories to Epics in arbitrary ways.

As you've discovered, there is some support from Sub-tasks to Stories. So it seems like it would follow that you could sum things up from Stories to Epics. Again, short answer: nope.

I wrote this rant last month about why automation in Jira is incapable of currently doing this. Many of us have tried to make this work, and failed.

There is a link to a related bug/suggestion in my rant, and you can vote for that to get fixed.

The only other approach I know is to explore the Atlassian Marketplace for an add-on to Jira that you can afford that will enhance your queries and operations on the results. That can get you to computing the result you need. But I don't have enough experience with them -- particularly how to use them within automation -- to help further. The instances I manage include minimal add-ons.

If you find a solution that does work for you, please share it here for others! Best wishes.

Hey Mykenna Cepek,

then I need to go with my workaround. It is almost possible, when you use the values fieldChange.from and depending on the Trigger Time-tracking (it's called Zeiterfassung in german, I can't really say how they translated it :D ).

With a lot of if and else-if I almost got it. I can show you my Automation if you want to. Maybe we can work together on some workarounds :).

But yeah, it would be cool to have something like for tasks and subtasks. Because the workround is error prone


Best Regards, 


Dear @Mykenna Cepek 

Thank you for such a detailed explaination of the problem. Could you please clarify some plugins/add-ons that can help to solve this problem?



Mykenna Cepek Community Leader Jul 13, 2021

Unfortunately, I have not researched Jira apps to solve this problem.

Hopefully others who have needed to address this in their instances can suggest some apps that they have found helpful.

We're currently using Tempo Timesheets to provide a solid aggregation of logged time at various levels (including Epics, but also with Accounts and Customers which are layered onto Jira by Tempo). We don't use the "timesheets" aspect of Tempo at all, but we make heavy use of the logged time reporting features which support our critical client-billing processes. This is a paid app (not cheap), but it's solid, and the time logging features (ease of entry, visibility of logged time, different views and reports, even a Chrome plug-in) really help support our time tracking needs.

@dennis.weinberger could you show me your automation if possible? I'm struggling to sum up estimates from stories into epics and can't get any meaningful results(((

Is it giving correct value for original estimates?


I tried to use the same logic, though the rule is triggering - it is not returning correct value. Example - In a story I have created 2 tasks, task 1 has Original estimate 2d 3h & task 2 has Original estimate 7h, so for story Original estimate should display as 3d 2h, however it is showing me a weird number like 45w or in week all the time for any hour estimation also. Can anyone point the mistakes?


Suggest an answer

Log in or Sign up to answer

Atlassian Community Events