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

[Alex Koxaras]

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

{{issue.fields.timetracking.originalEstimateSeconds.divide(60)}}

Step 5

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

Step 6

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

Pros

• It delivers and works!

Cons

• 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:

• lookupIssues available properties do not include custom fields
• I try using the {{#=}}{{/}} but I couldn't sum up the values
• This community question (and other similar) although promising in the beginning, didn't do any help

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

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.