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

[#1]

Last Edit Date:	17th August 2022
What's new:	Modified the rule to sum directly Original & Remaining Estimate to its values. Replaced images with new ones Removed old commentary which had no value to the new rule

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.

Rule

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 and log work
• Step 2: Rule keeps going only if the trigger issue type is specific
• Step 3: Create a branch for the parent of these issue types
• Step 4: Looks up to find all issues with the parent Epic Link
• Step 5: Sums up the original estimate and remaining estimate of the Epic's children

Rule Break Down

Below you will find each individual rule component.

Step 4

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

Step 5

{
  "fields": {
    "timetracking": {
      "originalEstimate" : "{{lookupIssues.Original Estimate.sum .divide(60)}}",
      "remainingEstimate" : "{{lookupIssues.Remaining Estimate.sum .divide(60)}}"
    }
  }
}

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.

Pros

• It delivers and works!

Cons

• This rule takes 3 to 3,2 seconds in duration (which I think is significant)
• It will not perform any calculation if you edit the Epic Link of the standard issue types, or if you delete an Epic's issue

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

Cheers,
Alex

[Bill Sheboy]

Thanks for the write-up, @Alex Koxaras -Relational- 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":

https://jira.atlassian.com/browse/JRACLOUD-75018

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:

https://jira.atlassian.com/browse/JRACLOUD-75019

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,

Bill

[Alex Koxaras -Relational-]

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

[Bill Sheboy]

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.

[Bill Sheboy]

Hi @Alex Koxaras -Relational- 

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.

https://community.atlassian.com/t5/Automation-articles/New-lookup-issues-fields/ba-p/1873978

Kind regards,
Bill

[Alex Koxaras -Relational-]

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!

[Simon Huprich]

Hi @Alex Koxaras -Relational- 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!

Greetings
Simon

[Simon Huprich]

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

[Bill Sheboy]

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,
Bill

[Simon Huprich]

Great!
Thank you

[Simon Huprich]

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

or

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




Thank you vey much
Greetings
Simon

[Bill Sheboy]

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: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[Simon Huprich]

Thank you very much!
Greetings!

[Cole Jackson]

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

Thanks!

Cole

[Cole Jackson]

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.

[Cole Jackson]

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)}}

[Simon Huprich]

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?

Situation:

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

Greetings
Simon 

[Fernando Cirino Sato]

@Alex Koxaras -Relational- @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!

[moe A]

hi

[moe A]

Hello, 

I am having trouble with an automation. I am using {{issue.fields.timetracking.originalEstimateSeconds.divide(60)}}.

I created a custom field to count the original estimates of stories under an epic, the value I'm getting to this field is only minutes, anyway to convert this value to hours? 

[Bill Sheboy]

Hi @moe A -- Welcome to the Atlassian Community!

First thing: I recommend creating a new question, linking to this old thread, and including images of your rule and the audit log details for context.  Otherwise only people following this older thread will see it to offer help.  Thanks!

Next, you are dividing Seconds by 60, which returns Minutes.  Please try dividing again (or with a higher value) if you want to convert Seconds to Hours.

Kind regards,
Bill

[Alex Koxaras -Relational-]

To all those who are interested, I've updated the initial article and it's now up to date!

[Simon Huprich]

Thank you,
I will try it as soon as possible
Greetings

[Simon Huprich]

Hey Alex,
so, I used your way to calculate estimates, but I don't get the correct results. I modified the automation exactly how you did it, but when the rules execute, the original estimate of the epic got set to "0m" all the time.
Do you have a hit for me?
Greetings
Simon

[Alex Koxaras -Relational-]

Can you post a screenshot of your rule, as well as it's audio log?

[Simon Huprich]

Hey Alex,

sure...

1. Rules

2. Execution

3. "0m"

Thank you very much!
Greetings
Simon