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

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:

rule_edited01.png

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

rule03 (lookupissues).png

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

Step 5

rule_edited02.png

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

66 comments

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 9, 2021

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

Like # people like this
Alex Koxaras _Relational_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 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. :/

Like Polina Semykina likes this
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 12, 2021

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 7, 2021

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_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 8, 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
Simon Huprich February 14, 2022

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

Screenshot 2022-02-14 195710.png

Simon Huprich February 14, 2022

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 14, 2022

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 February 14, 2022

Great!
Thank you

Simon Huprich February 14, 2022

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


Screenshot 2022-02-15 081519.png

Thank you vey much
Greetings
Simon

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 15, 2022

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/

Like Romans Averins likes this
Simon Huprich February 15, 2022

Thank you very much!
Greetings!

Like Bill Sheboy likes this
Cole Jackson February 17, 2022

@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

automation.png

Like Romans Averins likes this
Cole Jackson February 17, 2022

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 February 17, 2022

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
Simon Huprich February 17, 2022

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 March 17, 2022

@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 July 19, 2022

hi

moe A July 19, 2022

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 19, 2022

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_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 17, 2022

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

Like Bill Sheboy likes this
Simon Huprich August 17, 2022

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

Simon Huprich August 29, 2022

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_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 29, 2022

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

Simon Huprich August 30, 2022

Hey Alex,

sure...

1. Rules

2. Execution

3. "0m"

Screenshot 2022-08-30 091501.pngScreenshot 2022-08-30 091540.pngScreenshot 2022-08-30 091603.png

Thank you very much!
Greetings
Simon

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events