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

Calculate the sum of original estimates of all issue types to an Epic using Automation

Alex Koxaras Community Leader Apr 09, 2021

Hi all!

Recently I faced the problem of finding a way to sum up the original estimate of all issue types of an epic, without the use of an addon. I was going to use only the native automation that Jira provides. At first my manager gave me a hint of this example to follow and I thought that "hey! I could use this to solve my problem in no time!".

How little did I know :D

This example worked perfectly when you had stories and subtasks and you wanted to sum up story point. However my problem was a bit different. I had 4 different issue types (standard tasks) from which I wanted to sum up all original estimates and not story points. Long story short, after trying numerous ways and quite a few community proposed solutions, which in my case they didn't work, I came up with a kinda good workaround.


Below you will find my rule, which after testing it, it works like a charm:


So what the above rule does is that

  • Step 1: It tracks changes on Time Tracking
  • Step 2: Rule keeps going only if the trigger issue type is specific
  • Step 3: Get the original estimate value of the trigger issue and copy it on the Story Point field
  • Step 4: Create a branch for the parent of these issue types
  • Step 5: Looks up to find all issues with the parent Epic Link
  • Step 6: Sums up the story points of the Epic's children and copy it on the Original Estimate field

Rule Break Down

Below you will find each individual rule component.

Step 3

rule02 (edit story points).png


Step 5

rule03 (lookupissues).png

"Epic Link" = {{issue.key}}

Step 6

rule04 (edit original estimate value).png

{{lookupIssues.Story Points.sum}}


Ending Note

I though to end this discussion by presenting to you the pros and cons of this rule, as well as my justification in creating and following it.


  • It delivers and works!


  • Uses an extra field (story points) to do the copy/paste thus,
  • This rule takes 3 to 4 seconds in duration (which I think is significant)
  • Makes Story Point field obsolete, since it is used in the calculation, thus,
  • You can't use any chart that uses story point


Reasons for following this approach

In a few words: I couldn't find any better solution! I've tried numerous ways and wasted more that 7 hours before following this solution. I'm not going to list here all the ways I've tried, but to name a few:

I would very much like to discuss about this solution, and if you have anything better to suggest please do share!



Thanks for the write-up, @Alex Koxaras Great work improvising!

Here is my suggestion to add more fields to Lookup Issues access, however it seems to have moved to the dust bin of "future consideration":

And, here is a suggestion to make Created Variables editable, which would have also eliminated the need to use Story Points as a working variable:

I wonder if there is another field to use...

  • as Atlassian decided to create a new field of Story Point Estimate for next-gen, and
  • apparently you can set either that field or Story Points for an issue, and
  • both are available from Lookup Issues, so
  • Could you use the one you don't need for the working variable rather than walking on Story Points?  Then your built-in Story Point reports can still work.

Best regards,


Alex Koxaras Community Leader Apr 10, 2021

Hi @Bill Sheboy!

Thank you for your reply, as well as for informing this thread about your suggestions! Too bad that the first one ended up on the "future consideration" drawer.

Concerning your suggestion about using the Story Points estimates, I really don't know if my client will end up using this field.

One workaround would be to:

  • Create a variable (e.g. Temp) at the beginning of the rule
  • Copy the Story Point value on the Temp variable
  • Execute the rule as it is stated above
  • Copy back the value from Temp to the Story Point field
  • voila

However, this could end up increasing the execution time even more. :/

Hi Alex,

Regarding execution time, until we have more profiling information in the tools to confirm our understanding...the posts and documentation seem to indicate three trouble areas to watch for:

  1. Re-fetch
  2. Branching leading to asychronous processing (more than one issue)
  3. And use of JQL in general

Also, I just noted a possible racetrack error in your rule: 

  • The story points in the trigger issue are updated from time tracking...and
  • Soon after a Lookup Issues call tries to get that information with JQL

Please consider an alternative to reduce (but not eliminate) the impact, where you use 2 rules:

  1. Catch the time tracking change, saves the value in story points, and then updates the parent epic with a triggering indicator, such as a comment: "time to update Original Estimate, requested {{now}}"
  2. Catch the comment change, and sum up the Original Estimate.  This rule will need the option enabled for Allow rule trigger in details

The transition of one rule to the other will help slow things down enough to proceed.  The other alternative is to update your Lookup Issues JQL to exclude the trigger isssue, and to then manually add it to the total Original Estimate from a created variable, as you suggest.

Hi @Alex Koxaras 

In case you did not see it, Lookup Issues now supports most of the fields.  Please consider updating your article as that reduces the need to use Story Points as a proxy field to roll up other fields.

Kind regards,

Alex Koxaras Community Leader Dec 08, 2021

Hi @Bill Sheboy !

I've missed this update since I'm between projects which need my attention! I'll try to take a look asap and update this article. Thanx for the heads up!

Like Bill Sheboy likes this

Hi @Alex Koxaras Hi @Bill Sheboy 

Is there already an update available?

I tried to copy that workaround in my project, but I didn't work.
Maybe someone could help me a little.

Thank you very much!


Screenshot 2022-02-14 195710.png

Hi @Alex Koxaras Hi @Bill Sheboy 

I solved it on my own... :-)
I had to activate the Story Point option for my custom issue type

Hi @Simon Huprich 

The work-around of using story points to hold the original estimate values is no longer necessary when using Jira Cloud...Lookup Issues now supports all of the issues fields, and so you should be able to sum on that field directly from a lookup.

Kind regards,

Hi @Bill Sheboy 

One more question:

So I have to change the term "{{lookupIssues.Story Points.sum}}" to adapt it to "Original Estimate".

What would be the right way?

Something like:

{{lookupIssues.Original Estimate.sum}}


{{#lookupIssues}}{{original estimate.sum}}{{/}}

Screenshot 2022-02-15 081519.png

Thank you vey much

Hi, Simon.

I think the field's smart value is either "timeoriginalestimate" or "Original estimate", and to get just the sum for the lookup issues is:

{{lookupIssues.Original estimate.sum}}

You should not need the loop/iterator to do that.

By the way...when you need to confirm a field's smart value you can use this how-to article.  Essentially you call the REST API from a browser tab with an example story/issue and then search for your field:

Like Romans Averins likes this

Thank you very much!

Like Bill Sheboy likes this

@Bill Sheboy Thank you for answering @Simon Huprich , I had the same question.

I am having trouble with this particular automation. I am using {{lookupIssues.Original Estimate.sum}} and it doesn't appear to be working correctly.

Though all my issues linked to a parent epic contain hours for original estimates, the total that is placed in the epic by the automation is in weeks and the number doesn't correlate. 

Here's a simple example: 

I have one epic and one story. The story has an estimate of 2h. The automation runs and should place the sum in the original estimate field in the epic. But when I look, the sum is 3w. Any idea why? In this simple example, it should just be 2h. I am not understanding what is happening.




Like Romans Averins likes this

I think this may be the result of units or something along those lines. When I choose 1m for the story, the epic shows 1h. If I enter 1h in the story, the epic will now show 1w 2d 4h. 


Thanks again.

I solved my own issue.

This was units related. I recognized that the total was 60 times what I was entering. I resolved this by using the following:

{{lookupIssues.Original estimate.sum.divide(60)}}
Like # people like this

Hi @Cole Jackson
great that you solved your issue.

But now I have also a question.

I established the same structure of automation (Trigger, condition, action) and I also tried you last hint.

But sadly now I don't get an Original Estimate at all.

What do I miss something?


- 1x EPIC → Sum of hour, etc. of all child issues should be shown
-  several issues from a custom issue type called "Planning"
- the rule always executes ("success") but the Original Estimate always remains 0h

What do you think?


@Alex Koxaras @Bill Sheboy 

How was the workaround before lookupissue solution? Im asking this because my company uses Jira server and lookupissues is not a Jira server feature. Thank you!


Log in or Sign up to comment
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

14,947 views 38 49
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you