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; } } }

Sum of story points in i Epic using an automation flow doesn't work as expected

Alejandra Palacio Perez_ai2u5r

hi,

I struggle with your recommendation using the automation flow to sum the story points from child tasks into parent, totalt sotry point in Epic = Sum of story points from (task + story + bug).

It doesn't work all the time, for some epics it works and for others don't.

The other problem is that once I change a value within a task, it actually continue the counting as if it is a new task. I change the value from 6 to 0, and suddenly the sum was even higher in stead of reducing the total to minus -6.

You should have the functionality that sums the story points for parents as main functionality that you can add in the settings.

I have now tried to implement this rule during 2 days, and it doesn't work.

Other problem I experienced is the application is pretty slow. I don't know if it is because of the automation rule.

Please, help!

Bug in Jira Cloud 270726.jpg

Accepted answers

Gor Greyan

Hi @Alejandra Palacio Perez

Could you share a screenshot of the Edit issue action?

I'd like to see how the Story Points value is being calculated. The behavior you described suggests the rule may be updating the Epic by adding/subtracting values rather than recalculating the total from all child issues.

Marc -Devoteam-

Hi @Alejandra Palacio Perez

The rule is correct.

In the Epics with incorrect sums, are there work items from other spaces or are there unestimated work items?

As the other sums on Epic are correct, if I understand you.

So then it's not the rule, but it is related to the items in the Epic.

zoltanersek _outpostlabs_dev_

From your description, it doesn't sound like the Epic is being recalculated, it sounds like the rule is incrementing the existing value. A change from 6 → 0 should always reduce the total, not increase it.

I'd also check the Lookup issues step in the audit log. Does it return only the non-Done child issues you expect, and does the calculated sum match that list? That will quickly tell you whether the issue is with the JQL scope or the Edit Issue action itself.

If you can share the Lookup issues action and the Edit issue configuration, it should be easier to pinpoint where the calculation is going wrong.

Gabriela - LeanZero

Hi @Alejandra Palacio Perez, 154 against 147 is the giveaway. The status filter is on the trigger, not on the lookup. The JQL on the Feltverdi endret card only decides which child edit may start the flow. Søk etter arbeidsoppgaver has no status clause, so it sums every child, Ferdig and Utgått included. There's your 7 points.

Move the clause into the lookup:

parent = {{issue.key}} AND issuetype in (story, task, bug) AND status not in (Ferdig, Utgått)

then take the status part off the trigger and leave project and issuetype there.

12893 is the same cause from the other side. Editing points on a child that is already Ferdig or Utgått doesn't start the flow, so nothing gets written and the epic stays empty. The audit log won't show a run for those edits.

Your trigger only watches Story Points, so a child moving to Ferdig won't recalculate anything by itself. A second rule on Work item transitioned, same branch and lookup, covers that.

All comments

Gor Greyan

Hi @Alejandra Palacio Perez

Could you share a screenshot of the Edit issue action?

Alejandra Palacio Perez_ai2u5r

Hi
here it is.

And in the top, I have defined that it should only apply for status that are not Done (utgått, ferdig). I have actually replaced the "Ferdig" with Done after a test of the jql query. But the values are not correct yet. I added now the Audit log. The automation rule starts once I change story points in the User Story and it should sum all the story points within the epic.

And it takes 6.2 sec. too much time

Marc -Devoteam-

Hi @Alejandra Palacio Perez

The rule is correct.

In the Epics with incorrect sums, are there work items from other spaces or are there unestimated work items?

As the other sums on Epic are correct, if I understand you.

So then it's not the rule, but it is related to the items in the Epic.

Alejandra Palacio Perez_ai2u5r

Hi,
There aren't items from other spaces, but there are items without story points.

In the result where you see the Story point value = 154 in the Epic IFU-12573. It should be 147 without items with status Ferdig (Done) and Utgått (Closed).

It's weird that the rule work randomly too as you see, no value is added even if i have made changes in the field story pojnts for tasks and user stories.

zoltanersek _outpostlabs_dev_

If you can share the Lookup issues action and the Edit issue configuration, it should be easier to pinpoint where the calculation is going wrong.

Gabriela - LeanZero

Move the clause into the lookup:

parent = {{issue.key}} AND issuetype in (story, task, bug) AND status not in (Ferdig, Utgått)

then take the status part off the trigger and leave project and issuetype there.

Your trigger only watches Story Points, so a child moving to Ferdig won't recalculate anything by itself. A second rule on Work item transitioned, same branch and lookup, covers that.

Marc -Devoteam-

Hi @Alejandra Palacio Perez

A rule doesn't work randomly, it triggers on an action and executes on what is found.

But as also mentioned by @Gabriela - LeanZero the JQL (lookup) in the brach is wrong, this contains any work item in any status.

So if the rule is triggered and it passes the condition in the lookup all work items linked will be counted, including if a work item is Done or Closed)

Gor Greyan

Hey @Alejandra Palacio Perez
Thanks for the clarification.

The rule structure looks correct to me, so I don't think the calculation itself is the issue.

Since the result is inconsistent, could you add a Log action immediately after the Lookup issues action and log the following smart value?

If that value is already incorrect, then the issue is with the lookup (for example, not all child issues are being returned). If the logged value is correct but the Epic still receives the wrong Story Points, then the problem is occurring during the Edit issue action.

Alejandra Palacio Perez_ai2u5r

Yes, the Epic is not being recalculated.

Is this related to the rule in the top, the one that tryggers this automation rule or flow?

You can choose between "Values added", "Deleted values" and "Eventually changed values". I have chosen values added before. I don't see the difference.

Gabriela - LeanZero

Hi @Alejandra Palacio Perez, that dropdown isn't it. Your screenshot has Endre type on Eventuelle endringer i feltverdien, the widest of the three, so every Story Points edit is already getting through. Values added fires only when data is added to a field, Deleted values only when data is removed. That split mostly matters on multi-value fields like labels or organisations.

The same screenshot still has status not in (Done, utgått) on the trigger card, and Søk etter arbeidsoppgaver still reading parent = {{issue.key}} AND issuetype in (story, task, bug), so the total is still counting your Done children. Hent arbeidsoppgavedata på nytt won't move it either. That one refreshes {{issue}}, not the lookup result.

Alejandra Palacio Perez_ai2u5r

I have now try all your suggestions.

what I see is that the epic has more than 100 tasks, it may affect number of tasks it may count.

for that reason, I did the following:

In stead of asking for the sum of all the items, I just divided the tasks as you can see below.

But, it doesn't work.

Gabriela - LeanZero

The hundred is a hard ceiling on Cloud. Atlassian's action reference for Lookup work items reads "Search for up to 100 work items using a JQL query", and Cloud has no global config to raise it the way Data Center does. That's the "works for some epics and not others" from your first message. Under a hundred children the sum comes out complete, over it the lookup stops at 100 and the rest are left out of the total.

Splitting is the right instinct. What kills it is that each Lookup replaces {{lookupIssues}} with its own result, so by the time you reach Edit work item only the last slice is still there. Add a Create variable straight after each lookup holding {{lookupIssues.Story Points.sum}}, then add those variables together in the edit. IFU-12573's audit log should show that first lookup returning exactly 100.

Alejandra Palacio Perez_ai2u5r

Thanks a lot for the feedback, I will try that. It makes a lot of sence.

Danylo Iliukha _Appfire_

Hi @Alejandra Palacio Perez

The "works for some epics and not others" pattern usually comes down to two things in the automation approach:

The 100-item ceiling. On Cloud, the Lookup work items action returns at most 100 results, so any epic with more than 100 children silently drops the overflow from the total. That fits what you found once an epic grew past 100 tasks.
Where the status filter lives. The Done/closed clause has to be inside the lookup JQL itself (`parent = {{issue.key}} AND issuetype in (story, task, bug) AND status not in (Ferdig, Utgått)`), not only on the trigger. Otherwise every child is counted, which is where your 154 vs 147 gap comes from.

The reliable workaround people land on is splitting the lookup into slices, storing each `{{lookupIssues.Story Points.sum}}` in a Create variable, then adding the variables in the Edit action.

That said, if you'd rather not maintain automation for this at all and you're open to an app from the Atlassian Marketplace, this is something JXL for Jira handles natively. Its sum-ups roll story points (or any numeric field) up from children to the parent epic automatically and live, with no rule to trigger and no 100-item cap. You can also filter which children count, so Done and Utgått items stay out of the total, right in the view.

epic-story-point-sum-up

Full disclosure: I'm on the team that builds JXL.

Hope this helps,

Danylo

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-cloud