Can I automate Story point sums to populate the Epic points?

[Bud Herz]

We happen to have the Story Points field available on our Epics. 

Can we automate the following scenario:

Add points to a Story and the parent Epic points increment accordingly to reflect the TOTAL sum for all Story ticket children?

---------

Actually it should be as easy as a trigger for when the Story points change, save as a variable, then write that variable to the Epic

Am I on the right track?

[John Funk · Accepted solution]

Hi Bud, 

You should be able to find lots of examples of this in the Community. Here is one:

https://community.atlassian.com/forums/Automation-questions/Sum-up-Story-Points-from-Stories-Under-Epic-Jira-automation/qaq-p/2674049

[Bill Sheboy]

Hi @Bud Herz 

Yes, and...to John's suggestions: your license level and desired level of accuracy determine how to implement updates like this.

For example, let's assume you have unlimited rule usage and want the data as accurate as possible, as quickly as possible.  There are a bunch of scenarios to consider for accurate updates:

1. When a Story is created with a parent Epic, update the Epic
2. When an existing Story changes its field, update the Epic
3. When a Story without a parent Epic is assigned to an parent Epic, update the Epic
4. When a Story is removed from a parent Epic, update the previous Epic
5. When a Story changes its parent Epic, update the current and previous Epics
6. When a Story is deleted...
7. When a Story changes issue type such that it no longer has a parent...
8. When someone manually changes the field in the Epic, recalculate the sum
9. When Atlassian has another outage impacting automation, and one does not want to assume the automatic retry feature will work as expected, use a scheduled trigger rule which can update all desired Epics.  This rule could be left disabled unless needed.
10. etc.

Some of these cases may be merged while others require separate rules with different triggers.

However, when usage is limited or only periodic updates are needed, please see this article from John on using a scheduled trigger rule for updates, such as daily: 

https://community.atlassian.com/forums/Jira-articles/How-Can-I-Sum-Up-Multiple-Issues-into-a-Parent-Number-Field/ba-p/2882712

Kind regards,
Bill

[Bud Herz]

If I may be so bold to offer a catch phrase: With Bill Sheboy, you get the whole shabang

Those are great things to consider Bill. Much appreciated.
I'll have to take a better look at all of our work to see which is the most impact first. 

Thanks again!

[John Funk]

Yep, Bill is the GOAT of Jira Automation

[Bud Herz]

@Bill Sheboy  (or anyone else)
The following are the only obstacles that remain for my quest: Any help would be greatly appreciated.

1. When a Story is removed from a parent Epic, update the previous Epic
2. When a Story changes its parent Epic, update the current and previous Epics
3. When a Story is deleted...
4. When a Story changes issue type such that it no longer has a parent...
5. When someone manually changes the field in the Epic, recalculate the sum

Overall it's the moving from Epic to Epic that will not subtract the Story Points.

I have success adjusting them all day long if they remain under their parent Epic.
 
If moving them, the new Epic adds the new points, but the previous Epic does not subtract the points.

Here's a screenshot of my automation:

[Bill Sheboy]

Hey, @Bud Herz 

The keys for updating of the previous Epic's values for most of those cases are:

• only include the parent field with the Field Value Changed trigger, and
• that will allow using the changelog smart value with the {{fromString}}

With that, you may access the previous Epic's key to make the changes needed.

For the deleted case, that is special: the {{issue.parent}} should still contain the value while the rule is executing, allowing the value to be stored in a variable and then used with the Lookup Issues action and the branch on JQL.  Directly branching to parent may not work due to some special handling in rules for deleted issues.

For the "tampering" case, essentially you clone your current rule and change the logic to add a condition that the trigger issue is an Epic, alter the Lookup Issues JQL accordingly, and remove the branching.

[Bud Herz]

Thanks Bill!

[Karan Sachdev · Accepted solution]

Hey @Bud Herz

You may follow the rule template shared here: https://www.atlassian.com/software/jira/automation-template-library/rules#/rule/9919294

Thanks!

[Bud Herz]

Thanks @John Funk and @Karan Sachdev 
Those are both perfect! 

[John Funk]

Great to hear! And you are welcome