If you prefer to see the video walkthrough, you can do so here:
Keeping parent and child work items in sync is one of those Jira problems that doesn't look serious until you add it up. Estimates drift. Timelines diverge. Parents linger "in progress" after their children are long done. Each small inconsistency costs someone a few minutes, and those minutes stack up fast across an enterprise instance. Atlassian's State of Teams 2024 report puts the Fortune 500 cost of ineffective collaboration at 25 billion work hours a year. (Things haven't exactly gotten less expensive since then)
The good news: Jira's built-in automation can handle this without scripts or paid add-ons. Here are three patterns we build for clients at Sketch, an Atlassian Solution Partner, each from a short demo I recorded. Before rolling any of these out, test in a sandbox project and uncheck Allow rule trigger on the rule details page to prevent loops.
Say an epic is due April 10 with two stories underneath at April 8 and April 9. In the demo, I pushed the epic's due date out to April 17. Automation ran in the background, and the two stories shifted to April 15 and April 16. Same relative offsets as before: 2 days and 1 day before the epic. Moving the epic moved the whole delivery timeline without destroying the relationships between items. It works in the other direction too. Pull the epic in, children pull in by the same amount.
The rule triggers on Field value changed for Due date on epics, branches over children, and uses the changelog smart value to calculate the delta between the old and new epic dates and apply the same shift to each child. If you'd rather have children match the parent's date exactly, skip the delta math and set Due date to .
This is the best fit for delivery managers and scrum masters who own release timelines.
Same epic, different problem. The epic's Story Points field shows 5, which is the sum of its two children at 2 and 3 points. Nobody added those numbers manually. When I resized one story from 2 to 3 in the demo, the epic's rollup updated to 6 in real time.
For subtasks rolling up to a parent story, Atlassian provides an official template that uses one smart value:
Stories rolling up to an epic need a Lookup Issues action with the JQL "parent" = , then an Edit issue action setting the target field to . This pattern comes straight from Atlassian's knowledge base.
In the demo, I used the default Story Points field on the epic. A common upgrade is to write the rollup to a custom field called Story Point Rollup instead. That preserves the epic's original estimate in the default field so you can compare it against the rolled-up total and spot scope creep as it happens.
In the demo, a story has two subtasks. One is already done. I marked the second done, and automation transitioned the parent story to Done on its own. No manual cleanup.
The rule triggers on Issue transitioned to Done for child issue types, branches to the parent, and transitions the parent to Done if a JQL check confirms every sibling is already closed:
parent = AND status != Done
If that query returns zero results, all siblings are finished.
A word of warning here: this isn't right for every workflow. Skip it when parents need stakeholder acceptance, compliance sign-off, or integration testing after the children finish. It's a good fit for simple delivery workflows where the parent is really just a container for its children.
Related Reading: How to use Jira automation to create Confluence pages
No. Every rule here uses Jira's native automation engine, which is included with Jira Cloud and Data Center. Reach for ScriptRunner only when you hit a limit that smart values can't handle.
Usually a field name mismatch. In many Jira instances the field is called Story point estimate, not Story Points. Use the custom field ID (for example, issue.customfield_10016) instead of the display name to be safe. A Log action in your rule will show you what value the smart value is actually returning.
Yes. Lookup Issues returns a maximum of 100 results. If your epic has more than 100 child stories, you'll need a different approach, such as a scheduled rule that processes issues in batches.
These three rules are just the start. The possibilities with Jira automation are extensive, and the right set depends on how your team actually operates. At Sketch, we design, configure, and document Jira automation libraries for Fortune 500 clients and growing startups. Our US-based Atlassian Solution Partner team can build yours, or train your team to maintain one themselves.
Learn more about our Atlassian consulting services, or schedule a free consultation.