Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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:

Rule01.png

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

rule02 (edit story points).png

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

Step 5

rule03 (lookupissues).png

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

Step 6

rule04 (edit original estimate value).png

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

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

Cheers,
Alex

1 comment

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

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

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.

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Marketplace Apps & Integrations

Staying organized with Jira: best practices for a better project management

Project managers know this problem: A “mountain of work” lays in front of you, and you don’t know how and where to tackle them. Different to-dos lie ahead, but just one task after the other can be ha...

248 views 2 1
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you