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.
None of this is a Jira bug. 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.
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, if built correctly (lookup step, right field, right relationship) | Free, but brittle and easy to misconfigure |
| 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.