The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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
Below you will find each individual rule component.
{{issue.fields.timetracking.originalEstimateSeconds.divide(60)}}
"Epic Link" = {{issue.key}}
{{lookupIssues.Story Points.sum}}
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.
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!
Cheers,
Alex
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:
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:
Also, I just noted a possible racetrack error in your rule:
Please consider an alternative to reduce (but not eliminate) the impact, where you use 2 rules:
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.
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
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!
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!
Greetings
Simon
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
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
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
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/
@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
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)}}
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
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!
👋 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...
Connect with like-minded Atlassian users at free events near you!
Find an eventConnect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.
Host an eventYou're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events