August 12, 2026 · Jira

Story point rollup in Jira: what's native, what automation can do, and where both stop

Open an epic in Jira and its progress bar answers exactly one question: how many child work items are done. For teams that estimate in story points, that's rarely the question being asked. A 13-point story and a 1-point cleanup task count the same, and once your sub-tasks carry estimates, even the count is off — sub-task estimates don't roll up into the epic at all.

The question usually surfaces as "how do I sum story points from sub-tasks to the story, and from stories to the epic?" This post walks through what Jira does out of the box, how far an automation rule gets you, and the point where each approach runs out.

What rolls up natively

More than most people expect — but in scattered places:

The epic's issue view shows a progress indicator over its child work items — based on how many are done, not on estimates.
The backlog (company-managed projects) shows per-epic story point totals split by status when you open the epic panel — useful, but it lives in the backlog, not on the epic.
Plans (Premium) does real estimate rollup up the hierarchy — but it's a planning view you have to navigate to, and sub-task estimates are excluded from rollups entirely. If your team estimates at the sub-task level, Plans won't see those numbers.
Team-managed projects add a naming wrinkle: the field is "Story point estimate", not "Story points". Any rollup you build has to target the right field, and JQL or automation written for one project type quietly does nothing in the other.

Jira epic view with the native child work items progress bar showing 25% done while story point totals tell a different story — The native epic progress bar: 25% done by item count — 2 of 8 items closed — with story point columns visible.

The common thread: Jira shows you pieces of the answer on different screens, but no single place on the epic itself says "21 of 43 points done, and here's the breakdown." The gap is visible in the screenshot above — the epic's bar reads 25%, two of eight items closed, while by story points the same epic is 49% done, because the two closed items happen to be the biggest ones.

The automation approach

The standard workaround is an automation rule that maintains the rollup in a custom field:

Create a number field, e.g. "SP rollup", on stories and epics.
Rule 1: when Story points changes on a sub-task → branch to its parent → sum the estimates of all the parent's sub-tasks (a lookup with {{lookupIssues.Story Points.sum|0}}) → write the result to the story's rollup field.
Rule 2: same shape one level up — when a story's rollup changes, re-sum into the epic.

Jira automation rule that sums story points from sub-tasks into the parent story's rollup field — Rule 1 of the pipeline — sub-task estimates summed into the parent story on every change.

This genuinely works, and if you just need the number to exist — for JQL, for a dashboard gadget, for a report — it's a fine answer. The trade-offs only show up as you live with it:

It's one rule per level. Sub-task → story → epic is two rules, plus the custom field on every level. Add an initiative layer and you're maintaining a pipeline.
The value is only as fresh as the last trigger. Bulk edits, imports, moved issues, or a rule that was briefly disabled all leave stale numbers behind, and nothing flags the drift — the field looks exactly as authoritative when it's wrong.
Both story point field names need handling if you have a mix of team-managed and company-managed projects.
You get a number, not a picture. The rollup lands in a field. Progress toward done, or how the remaining work is distributed across assignees, still isn't visible anywhere on the epic.

Which route fits

Stay native if done-count progress is honest for your team — stories sized similarly, no sub-task estimates — or if you're on Premium and your PMs already live in Plans.
Use automation if you need the total as data (JQL filters, dashboards) and you're comfortable owning the rules. One hierarchy level and a number field is automation's sweet spot.
Use a marketplace app if you want the rollup computed live at view time — no rules to maintain, nothing to drift — shown on the issue itself, and broken down: not just "21 of 43" but who has how much of the remainder, in what state.

How Plugio Panels handles it

That third branch is what our app Plugio Panels covers. It adds configurable panels to the Jira issue view that compute rollups at view time, over the sources you choose — sub-tasks, direct children, or the full hierarchy under an epic:

The Progress widget weights progress by issue count, story points (both field names handled), time estimates, or any numeric field.
The Breakdown widget splits the same numbers by assignee, status, or any field — so "21 of 43 done" comes with who owns the remaining 22.
The mixed-estimate case this article keeps running into — a story and its sub-tasks both carrying points — is handled by a per-field overlap setting that decides which level counts, so nothing is silently doubled.

Plugio Panels on a Jira epic: delivery progress at 49% by story points with a per-assignee breakdown of remaining work — The same epic through Plugio Panels — 49% delivery progress by story points (21/43), with the remaining work broken down per assignee.

Because everything is computed when the page renders, there are no rules to maintain and no stale fields — the number on the epic is always the number in the data. Panels is one of several rollup apps on the Marketplace with different angles; if your need is only the raw total in a field, automation remains a perfectly good answer.

Try it on your own hierarchy. Plugio Panels is available on the Atlassian Marketplace, and the documentation covers every widget and setting.