nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Alex Koxaras -Relational-

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

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

rule03 (lookupissues).png

"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

Comments

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:

Re-fetch
Branching leading to asychronous processing (more than one issue)
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:

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

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_ky4jnq

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_ky4jnq

Great!
Thank you

Simon Huprich_ky4jnq

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

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_ky4jnq

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_ky4jnq

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

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_ky4jnq

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

Simon Huprich_ky4jnq

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_ky4jnq

Hey Alex,

sure...

1. Rules

2. Execution

3. "0m"

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

Thank you very much!
Greetings
Simon

Alex Koxaras -Relational-

Simon your rule seems ok. I've tested again my own and it's working alright.

I know that this can be a dumb thing to say, but you please check that your task/planung issue type has indeed a value? And when you make sure of that, can you go ahead and refresh the Epic page? It takes a while to update the field with the value.

Simon Huprich_ky4jnq

Hey Alex,
All the issue which are part of the epic have a value.
When the rule executes automatically, the value that I added manually was changed to "0m" again. (from 2h to 0m)

Alex Koxaras -Relational-

Simon, copy and paste the following JSON to a new JSON file and import it as a new rule.

{
"cloud": true,
"rules": [
{
"id": 4585207,
"clientKey": "392b6b84-aff8-31f3-bbcf-d4dc4de7f1a3",
"name": "MINE: Sum Original Estimate in Epic",
"state": "ENABLED",
"description": null,
"authorAccountId": "5f9fb7c1c2e5390077abf628",
"actor": {
"type": "ACCOUNT_ID",
"value": "557058:f58131cb-b67d-43c7-b30d-6b58d40bd077"
},
"created": 1639726658951,
"updated": 1661844588245,
"trigger": {
"id": "159519843",
"component": "TRIGGER",
"parentId": null,
"conditionParentId": null,
"schemaVersion": 2,
"type": "jira.issue.field.changed",
"value": {
"changeType": "ANY_CHANGE",
"fields": [
{
"value": "timetracking",
"type": "field"
},
{
"value": "worklog",
"type": "field"
}
],
"actions": [
"edit"
]
},
"children": [],
"conditions": [],
"connectionId": null
},
"components": [
{
"id": "159519844",
"component": "CONDITION",
"parentId": null,
"conditionParentId": null,
"schemaVersion": 3,
"type": "jira.issue.condition",
"value": {
"selectedField": {
"type": "ID",
"value": "issuetype"
},
"selectedFieldType": "issuetype",
"comparison": "ONE_OF",
"compareValue": {
"type": "ID",
"modifier": null,
"value": "[\"10002\",\"10004\",\"10001\"]",
"multiValue": true,
"source": null
}
},
"children": [],
"conditions": [],
"connectionId": null
},
{
"id": "159519845",
"component": "BRANCH",
"parentId": null,
"conditionParentId": null,
"schemaVersion": 1,
"type": "jira.issue.related",
"value": {
"relatedType": "epic",
"jql": "",
"linkTypes": [],
"onlyUpdatedIssues": false,
"similarityLimit": 40,
"compareValue": 0
},
"children": [
{
"id": "159519846",
"component": "ACTION",
"parentId": "159519845",
"conditionParentId": null,
"schemaVersion": 1,
"type": "jira.lookup.issues",
"value": {
"id": "_customsmartvalue_id_1639726474486",
"name": {
"type": "FREE",
"value": "lookupIssues"
},
"type": "JQL",
"query": {
"type": "SMART",
"value": "\"Epic Link\" = {{issue.key}}"
},
"lazy": false
},
"children": [],
"conditions": [],
"connectionId": null
},
{
"id": "159519847",
"component": "ACTION",
"parentId": "159519845",
"conditionParentId": null,
"schemaVersion": 10,
"type": "jira.issue.edit",
"value": {
"operations": [],
"advancedFields": "{\n \"fields\": {\n \"timetracking\": {\n \"originalEstimate\" : \"{{lookupIssues.Original Estimate.sum .divide(60)}}\",\n \"remainingEstimate\" : \"{{lookupIssues.Remaining Estimate.sum .divide(60)}}\"\n }\n }\n}",
"sendNotifications": false
},
"children": [],
"conditions": [],
"connectionId": null
}
],
"conditions": [],
"connectionId": null
}
],
"canOtherRuleTrigger": false,
"notifyOnError": "FIRSTERROR",
"projects": [
{
"projectId": "10005",
"projectTypeKey": "software"
}
],
"labels": [],
"tags": [
{
"id": 13693947,
"tagType": "IS_RULE_UPDATED",
"tagValue": "true"
}
],
"ruleScope": {
"resources": [
"ari:cloud:jira:f1b53191-2545-46a7-841f-975e03eb0b9f:project/10005"
]
},
"writeAccessType": "UNRESTRICTED",
"collaborators": []
}
]
}

If the above rule fail to update the epic, then most likely something else is happening.

Try it and let me know.

Andreea Cetateanu

Hi @Alex Koxaras -Relational- ,

After a lengthy search about how to create a rule that adds up Original estimate and Time remaining from a Story to an Epic, your post was a breath of fresh air. However, it seems that it is working only for Original estimates field, for me this rule is not working on of Time remaining field (the hours are not 'removed' at an Epic level when I log hours on a Story level).

I use an additional add on for time tracking (Tempo) is this the issue? or is there another issue?

P.S.: I only started to work with Jira Rules today.

Your answer is much appreciated!

Best regards,

Andreea

Alex Koxaras -Relational-

Hi @Andreea Cetateanu and welcome to the community!

So what you are telling me is that:

You have implemented the rule
The rule runs properly and add the Original Estimate
But it doesn't do the same for the Remaining Estimate

For all your issues you use tempo to log your work. Correct?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

app

automation

story-points

smart-value

sum