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

Story Points rollup to epic

Omkar Rajale

Hi,

I currently have an automation running that rolls up story points to the epic. However, it uses lookup Issues, which is limited to querying only 100 results. Some of my epics have more than 100 child stories, so the automation only sums the top 100 issues and ignores the rest. Is there any solution for this?

Accepted answers

John Funk

Hi Omkar,

One option might be to see if you can you the changeLog function to determine the difference in the value of the field when it was updated (negative or positive). Then use that value to change the parent value by the same amount. You would use a Field Value Changed trigger on the Story points field with a condition for issuetype = Story or issuetype in (Story, Task) if you are including those.

All comments

Michael Yaroshefsky - Visor for Jira

Hi @Omkar Rajale

In my experience most Jira users use 3rd party apps like Scriptrunner, Automation Toolbox, or JMWE, either using built in functions or Groovy scripts to overcome the 100 issues barrier.

Of course you could always look at restructuring your epics into separate epics so that you avoid having epics with more than 100 child issues, which might generally be a good idea, however I realize there may be some situations where a single epic just has to be that big!

We're actually working on something more elegant for this at Visor (my app) now, which has a bi-directional Jira integration and is already popular with Jira users to create Jira Gantt charts, roadmaps, tables, and dashboards.

We're going to give users the additional capability to add rollup calculations to these views, so they can accomplish exactly what you're talking about more easily. You'll also be able to do this across multiple projects in the same view. We're not quite there yet, however keep a look out for us as we plan to deliver this functionality very soon and you seem like the kind of person that would really get a lot out of it.

Hope that helps!

John Funk

Hi Omkar,

Bill Sheboy

Hi @Omkar Rajale

First, it seems unusual to me having over 100 child issues for a single Epic. I recommend pausing to understand why there are so many child issues to identify if there is another structure that would help: multiple Epics, add a level to the hierarchy, evaluate how Epics are used, etc.

Next, adding to John's suggestions...

There is no automation rule workaround for the 100 issue limit, even with the REST API, using a direct lookup of the issues. (i.e., Although up to 5000 issue IDs may be found at once, no other fields may be loaded above the 100 issue limit.)

If you try the approach John suggests by making the updates when the field changes in a child issue of the Epic, remember to include enough rules / logic to handle all possible cases. For example:

when an Story is created with an Epic assigned
when the field changes in a Story assigned to an Epic
when a Story is first assigned to an Epic
when a Story is removed from an Epic
when a Story is assigned to a different Epic
when a Story is deleted
when someone manual changes the calculated sum in the Epic
etc.

Other options are using marketplace addons / apps or building your own service capable of exceeding the limit by repeatedly calling the REST API endpoints.

Kind regards,
Bill

Bill Sheboy

Hi @Omkar Rajale

Just following up to check if this answered your question. If so, please consider marking this one as "answered". That will help others with a similar need find solutions faster. If not, please let the community know what help you need with the rule changes.

Thanks!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation