How to aggregate field values for issues in a sprint using Jira Automation?

[Gezim Basha]

I'm interested in calculating aggregate values using Jira Automation, basically sums of field values such as Story Points and Original Estimate/Remaining Estimate of issues that share a Sprint. Ideally, this would be done during sprint planning - therefore I would be able to know the aggregated original estimate for all issues.

As an example, consider Assignee A has selected 3 issues for 'Sprint X', each of them having various 'originalEstimate' values. I would like to know if Assignee A is overloaded in 'Sprint X', i.e. the sum of all 'originalEstimate' in days would be larger than 10 days (2wk sprint).

I've tried doing it this way, but I can clearly see that I cannot edit a created variable on the 'For JQL' loop. I've also tried using a 'Lookup Issues' loop, but that didn't accumulate 'originalEstimate' value.

Any ideas?

[Bill Sheboy]

Hi @Gezim Basha 

You are correct about no edit for created variables, which is why I suggested this:

https://jira.atlassian.com/browse/JRACLOUD-75019

...and, limited access to fields with lookupIssues, which is why I suggested this:

https://jira.atlassian.com/browse/JRACLOUD-75018

...and, created variables have scoping limits.  There is an article describing the use of created variables to preserve the value outside of a branch...but it only works when there is one-and-only-one issue for the branch.  Otherwise shadowing appears to clear the value repeatedly.

What work-arounds could you do instead...

• Use a custom field or entity property to store the sum and repeatedly re-fetch in the rule loop and make additions/updates.  That will definitely be slow, and might lead to some unintended side effects.  (I am guessing the rule engine may not like the re-fetch with the asynchronous processing in a loop.) 
• Try some dashboard gadgets and filters based upon the current sprint, or use a filter subscription to review the results after planning
• Or, use the Excel or Google Sheets add-ons to pull the data live, and build your own report to use during sprint planning

Best regards,

Bill