No — as of the 2026 Summer Release, Jira still has no native way to make a parent Epic’s Story Points field show the sum of its children’s story points. Automation rules can fake it, Premium’s Advanced Roadmaps can display it inside a Plan, and the new formula fields calculate values within one issue — but nothing writes a real cross-issue sum onto the parent’s own field. Two long-running Atlassian Community threads ask almost this exact question, and both end in “build it with automation,” not “here’s the setting.”
What people are actually stuck on
Two threads carry this problem, both still open on the Atlassian Community:
- “How to sum the original estimate from children to parent?” — 2,079 views. The asker wanted an automation rule that totals child issues’ original estimates onto the parent Epic. The fix that worked: removing an unnecessary “For: Parent” branch, since the Epic was already the trigger issue — then a follow-up question about extending the same rule across three hierarchy levels (Epic → Task → Subtask) that never fully resolved in the thread.
- “Why the sum of story points = 0?” — 1,791 views. The rule’s smart value,
{{lookupIssues.Story points.sum|0}}, kept returning0because it referenced a Lookup Issues action that was never run first in the rule. Once that step was added, it worked — but as the asker put it back to the thread, “it will be easier if you say that a lookup is mandatory.”
Neither thread ends with “here’s a Jira setting for that.” Both end with a hand-built automation rule, assembled from smart-value syntax that has to be gotten exactly right.
Why the sum comes back 0 (or doesn’t run at all)
The pattern across both threads and a handful of related ones — “Sum up story points to an epic” among them — comes down to a small set of repeat mistakes:
- A missing Lookup Issues step.
{{lookupIssues.Story points.sum}}only has something to sum if a prior action actually looked up the child issues; skip that step and the smart value quietly evaluates to nothing or to its own fallback. - The wrong field name. Company-managed projects expose “Story Points”; team-managed projects expose “Story point estimate.” They’re the same concept, labelled differently, and a smart value pointed at the wrong one returns nothing.
- The wrong relationship. Stories are children of an Epic, not sub-tasks of it — rules built around
Parent LinkversusParentbehave differently depending which hierarchy level triggered the rule, and it’s easy to build a rule that watches the wrong field. - Issues added after the fact. A rule triggered by “when Story Points changes on a child” never fires for a child that gets added to or removed from the Epic without its own points changing — so the total silently drifts.
- Changing the Parent field can fire the rule twice. This part is a documented Jira bug, not just a configuration slip: AUTO-1737 (closed as a duplicate of the broader AUTO-1616, 5 watchers) confirms that a rule using the “Field value changed” trigger on the Parent field runs twice when an issue is created with its parent already set — one event fires for the creation, a second for the update, and the rule reacts to both. Atlassian’s own knowledge-base article on duplicated actions documents the same double-fire for an issue moved or re-parented between projects — the move and the field change are two separate events, processed separately, so the rule executes twice for one real change. An action that adds to a number field instead of recomputing a fresh sum will double-count every time that happens; Atlassian’s documented fix is to scope the trigger to one specific operation (e.g., “Edit issue” only), not a setting that closes the gap on its own.
- The total is a snapshot of the last trigger, not a live number. None of these rules recompute on a timer by default — they fire when a watched field changes, so the parent’s rolled-up total reflects “whatever the rule last computed,” not a continuously accurate sum. Point 4 above is one way that shows up; a bulk edit, an import, or a briefly disabled rule are others, and none of them leave a visible warning that the number is stale.
None of this is a Jira bug — except AUTO-1737 itself, which is. It’s what happens when the only tool for a cross-issue calculation is an automation rule assembled from string-matched smart values, with no built-in way to see whether it’s actually summing the field you think it is.
Does any of this change if the field isn’t Story Points?
No — everything above applies to any custom number field, not just Story Points. A separate Community thread, “Jira Automation to Roll Up Custom Field (Number) to Parent Item” — 1,123 views — asks the identical question for a custom “Lesson Count” number field on subtasks, and gets the identical fix: a Lookup Work Items action, then a smart value like {{lookupIssues.customfield_XXXXX.sum}} on the Edit Issue action. The accepted answer explains why the obvious shortcut fails: {{issue.subtasks.myCustomField.sum}} looks like it should work without a lookup step at all, but “the subtasks smart value only contains some of the fields for each one” — so summing straight off it silently comes up short, same as the missing-lookup failure mode above, just with a different field name in the smart value.
Go one level higher in the hierarchy and it gets genuinely harder, not just relabelled. Atlassian’s own support article, “How to create a rule that sums up the values from number custom field from Epic to a Parent issue”, walks through summing a custom “Custom Estimate” number field from Epic up to a Feature — and states plainly that “the ‘Parent’ branch does not work for issue type hierarchy above the ‘Epic’,” because Advanced Roadmaps’ Parent Link field isn’t supported by that branch action. Atlassian’s own documented workaround drops the simple point-and-click branch rule entirely in favor of a Send Web Request action that hits the REST API’s JQL search directly, followed by a JQL branch to write the sum back onto the parent. So the exact same rollup — sum a number field from children onto a parent — is a few clicks at Epic level and a hand-built REST call one level up.
Does an automation-rule rollup handle issues getting re-parented, or risk double-counting?
Concretely, yes to both, and Atlassian’s own bug tracker and documentation confirm the mechanism rather than leaving it to guesswork. AUTO-1737 — closed as a duplicate of the broader AUTO-1616 — documents that a rule using the “Field value changed” trigger on the Parent field fires twice when an issue is created with its parent already set: one event for the issue’s creation, a second for the resulting update, and the rule reacts to both. Atlassian’s own knowledge-base article on duplicated actions shows the same double-fire for the re-parenting case that actually matters here: move an issue to a new parent (or a new project) and two separate events — the move, and the field change it causes — get processed separately, so the rule executes twice for what was really one change.
Whether that turns into a double-counted parent total depends entirely on how the rule’s action is written. A rule that recomputes the sum fresh each time ({{lookupIssues.Story points.sum}}, re-running the lookup every execution) just runs the same calculation twice and lands on the same correct number both times — wasteful, not wrong. A rule that adds a child’s value to the parent’s existing total instead of recalculating it from scratch will add that value twice, silently inflating the parent’s number every time a re-parent, a project move, or a creation-with-parent-set double-fires the trigger. Atlassian’s documented fix is procedural: scope the trigger to one specific operation (e.g., “Edit issue” only) rather than leaving it open to every event that can touch the Parent field — there’s no setting that makes a rollup rule immune to this on its own.
Do the 2026 formula fields change this? Checked directly against Atlassian’s docs — no
Jira’s 2026 Summer Release is real, and it’s tempting to assume it finally closes this gap: it merged List and All Work into one List view with “full parent/child hierarchy,” and it shipped formula fields that calculate values like remaining budget, days to deadline, or weighted priority scores directly on a work item — describable in plain language, per the release announcement.
But Atlassian’s own supported-functions documentation draws the boundary explicitly:
“A formula can only run using data within a single work item. For example, a formula field on work item A can only calculate the sum of costs already shown on work item A. It can’t calculate costs across work items B and C, or any other work item.”
That sentence is the whole answer. A formula field can combine fields that already live on one issue — multiply story points by a cost-per-point custom field, say — but it cannot reach into an Epic’s children and total their story points, because a formula never sees another issue’s data at all. “Full parent/child hierarchy” in List view is a display and grouping capability: you can nest child issues under their parent and expand/collapse them. It is not a calculation engine that spans issues, and Atlassian doesn’t claim it is one.
(A handful of paid Marketplace apps — built specifically as formula-field extensions — do offer cross-work-item rollup formulas layered on top of the native field type. That’s a real, working answer, and also a separate purchase and a separate app to configure, not something the box provides.)
What Jira Premium’s Advanced Roadmaps (Plans) actually does
Plans — Advanced Roadmaps, available on Premium and Enterprise — comes closest to a real answer, and it’s worth being precise about what “closest” means. Per Atlassian’s own documentation on rolling up values to parent issues, a Plan can show an aggregated estimate on a parent issue, marked with an up-arrow icon, turned on under View Settings → Roll-up. It’s genuinely dynamic — the rolled-up number shrinks as child issues log time or get marked done, not a one-time calculation.
The catch, confirmed by a recurring class of Community questions like “Aggregated Story points at Epic level not showing in Improved Interface view?”, is that this rollup is a feature of the Plan’s own interface — you have to open that specific Plan and have that Roll-up setting turned on to see it at all, and it’s gated to a Premium or Enterprise seat. It doesn’t write the total back onto the Epic’s actual Story Points field, so the same Epic viewed in the backlog, on a board, in the new List view, or pulled into a dashboard or JQL export still shows whatever number a person manually typed in — not the live sum of its children.
The honest summary
| Path | Does it sum children to parent? | Cost |
|---|---|---|
| Epic’s own Story Points field | No — it’s a manually entered number, never recalculated | Free |
| 2026 formula fields | No — explicitly single-work-item only, per Atlassian’s own docs | Free (Jira Cloud, all editions) |
| Jira Automation rule | Yes, for Story Points or any custom number field — if built correctly (lookup step, right field, right relationship, re-parent-safe trigger) | Free, but brittle; needs a REST workaround above Epic level |
| Premium/Enterprise Plans roll-up | Yes, but only inside that Plan’s own timeline view | Premium/Enterprise seat required |
| Third-party formula-extension app | Yes, natively as a field | A separate Marketplace purchase |
If your search brought you here expecting a checkbox somewhere in Jira settings, there isn’t one — every real answer above is either a rule you build and maintain, a view you have to be inside to see the number, or a separate purchase.
What OneView does instead
OneView signs in with your real Atlassian account, reads the same story points already sitting on your issues, and computes the rollup live — no automation rule to build and re-check, no Premium Plan to open just to see one number. It shows the total as a real column next to every parent in a grid you group and shape yourself: by Epic, by initiative, by whatever hierarchy you actually work in, across as many projects (or sites) as your work spans. It’s the same underlying job Plans’ roll-up arrow does, minus the requirement to live inside one Plan’s timeline to see it. Start a free trial and point it at an Epic with real children.
Related reading
Rollups are one piece of a bigger gap — Jira’s List view added hierarchy and grouping, but not everything people ask for around structuring work across issues. If your actual problem is scope rather than shape, see all my Jira tickets across projects (rolling up your own tickets across projects, and the harder wall of a second Atlassian site) and a Jira report across two sites (why no native tool, including Marketplace apps, crosses a site boundary at all). If your gap is depth rather than a number — you need a level above Epic, not just a total rolled up to it — see a hierarchy level above Epic in Jira. And if the rollup you actually need is a manager’s-eye dashboard rather than one parent’s total, see a Jira dashboard across multiple projects. Same underlying limitation as this page — a field, a view, or a login boundary that Jira’s native surfaces don’t extend past — just applied to a different axis of the same problem. And if you’re weighing whether Structure’s own Formulas feature solves this better than Plans’ partial roll-up, see Structure vs Advanced Roadmaps (Plans) in Jira. If the number you actually need isn’t a raw Story Points sum but a status split — % done, % in progress, % not started, under an Epic or Initiative — that’s a different rollup covered in a Jira epic percent complete report.