How to sum story points across epics and projects in Jira

You planned a quarter of work in Jira. Now someone asks a completely reasonable question — “how many story points is all of this?” — and you discover that Jira has no obvious button for it. This guide walks through every way to get that number, in plain language, including where each approach quietly stops working.

First, the vocabulary (30 seconds)

• Story points are the numbers teams put on issues to express effort. In Jira they live in a numeric field — usually called Story Points or Story point estimate.
• The hierarchy is how Jira nests work: an epic (a big goal) contains stories and tasks (concrete pieces), which can contain subtasks (steps). Larger setups add levels above epics.
• A rollup means: every level shows the total of everything underneath it. That’s the number people actually ask for.

What Jira gives you out of the box

1. The backlog and sprint headers. On a Scrum board, each sprint shows a small sum of its issues’ points. Useful — but it is per sprint, counts only what is on that one board, and knows nothing about hierarchy.

2. The epic’s own progress bar. Open an epic and you will see progress based on its direct children. Two catches: it typically counts issues done, not story points, and it will not follow deeper nesting or children living in another project.

3. Two Dimensional Filter Statistics gadget. A classic dashboard gadget that builds a table from any filter — but it counts issues. It cannot sum a numeric field, which is exactly what you need.

4. JQL search. JQL is great at finding issues ("Epic Link" = PROJ-42), but a search result in Jira Cloud does not display a sum of a field. You get a list, not a total.

5. Export to a spreadsheet. Always works, always manual: export CSV, build a pivot table, repeat next week when the numbers change. Fine once; painful as a routine.

6. Automation rules. You can build a rule that adds up children’s points into a custom field on the parent (a “smart value” sum). This genuinely works — but you maintain a rule per level, it recalculates only when the rule fires, it double-counts if you are not careful about which levels carry estimates, and cross-project totals get ugly fast.

Where all of this stops

Notice the pattern: each native option handles one flat slice — one sprint, one epic’s direct children, one filter. None of them will:

• follow the hierarchy to any depth (subtask → story → epic → above);
• cross project boundaries (“all four teams working on this initiative”);
• keep totals honest when some issues simply have no estimate yet.

That last point matters more than it sounds. A total that silently treats unestimated work as zero looks precise and is quietly wrong — sixty issues nobody has sized yet are unknown effort, not zero effort.

What a purpose-built rollup app does

Marketplace apps exist because this gap is real. A good one gives you, on a dashboard, a tree of your epics with totals at every level, across projects, with unestimated work counted and visible rather than hidden:

Our take on this is Hierarchy Totals, and it is built around one architectural decision: totals are computed in the background before you open the dashboard, not while you wait. That is why it stays instant on portfolios of tens of thousands of issues, shows a “data as of” stamp instead of pretending to be magic, and can keep daily history of your totals — a burndown you never had to maintain. It never sends data outside your Jira, and every number can be drilled down to the exact issues behind it.

Quick decision guide

You need	Use
Points in one sprint	The board header — free, built in
Progress of one epic, roughly	The epic screen — free, built in
Issue counts by category	Two Dimensional Filter Statistics — free
A one-off number for a meeting	CSV export + spreadsheet
Live totals with hierarchy, across projects	A rollup app such as Hierarchy Totals