Disclosure first: I build Sumline, the app in the last section. Everything before it is Jira's own behaviour and two free ways to get a right total.
Your site has both kinds of space: a company-managed space the platform team set up years ago, and the team-managed spaces every new team gets by default. Someone asks for story points per epic, and the number that comes back is wrong. Not a little wrong: whole teams missing, or an epic that reads 80% done with nothing shipped. Here is why, and three ways to get it right.
Why the total is wrong
1. Jira does not add story points up. Its Σ fields (Σ Original Estimate, Σ Time Spent, Σ Remaining Estimate) are time tracking only; there is no Σ Story Points. Atlassian's request to sum story points up to the epic is marked "Not Being Considered" (JRACLOUD-90636), and the request to sum sub-task points into the story, with 1,735 votes, was closed pointing to an Automation template (JRACLOUD-92573). The Epic report on a company-managed Scrum board shows one epic's complete, incomplete and unestimated points, one epic at a time, in one estimation field. Plans, on Premium and Enterprise, rolls estimates up inside the plan, not on the epic.
2. There are two story-points fields. Company-managed spaces use Story Points, a number field Jira Software adds. Team-managed spaces use Story point estimate, Jira's own field (Atlassian's smart values reference). They are different fields, so a JQL column, an export, a dashboard gadget or an Automation rule built on one reads nothing in the other kind of space. That is why a rule copied from a Community answer "works in one project and not the other": it is reading the wrong field there, and an empty field sums to 0.
3. Two mistakes that add up quietly. Once you sum the points yourself, two things go wrong without an error:
- Counted twice. A story estimated at 5 whose sub-tasks are estimated at 3 in total is 8 if you add every level. The work is 5, or it is 3, never both. Any sum over
parent = EPIC-1 plus its sub-tasks does this unless one level is left out on purpose. - Counted as zero. A story with no estimate adds 0 to the total and 0 to "remaining", so an epic with six unestimated stories reads as nearly done. The epic's number looks right and is not.
1. An export (free, a few minutes)
For a number now and then, a spreadsheet gets it right if you decide the two things above yourself.
- Search across the spaces:
project in (WEB, PAY, APP) AND issuetype in (Story, Task, Bug). Leave sub-tasks out, or include them and leave stories out, so each piece of work is in the list once. - Add the columns Parent, Story Points and Story point estimate. Every row fills one of the two.
- Export to CSV. In the spreadsheet, add the two points columns into one, and total it by Parent with a pivot table. Count the rows with no points per parent: that is the unestimated work.
It is a snapshot, as current as the export, and it stops at the epic: a total per initiative needs the epics' parents as well.
2. An Automation rule (free, needs a Jira admin)
Atlassian's knowledge base rule keeps a total in a field. Writing into a field of its own, rather than the epic's Story Points, keeps the epic's own estimate and the stories' sum apart so they can be compared:
- Create a number field, Story points total, and add it to epics in every space.
- Trigger: Field value changed → Story Points. In a team-managed space, Story point estimate. A rule has one trigger, so a site with both kinds of space needs two rules.
- Condition: the work item has a parent.
- Branch: Parent. Inside it, Lookup work items with
parent = {{issue.key}}, then Edit work item → Story points total = {{lookupIssues.Story Points.sum|0}}, or {{lookupIssues.Story point estimate.sum|0}} for a team-managed space.
Where it stops:
- The total is as fresh as the triggers. A story moved to another epic, a deleted story, and anything estimated before the rule existed leave the old total until something else changes.
- A lookup returns at most 100 work items, and every run counts toward your site's Automation usage.
- Sub-tasks need a rule of their own at story level, and then the epic rule counts the story's own points, so pick one level and estimate only there, or the total counts both.
- Nothing names the unestimated stories; the total just leaves them out.
3. Sumline (disclosure: I build it)
Sumline reads the right field in every space and adds up with the two mistakes handled, on the epic itself:
- Both fields, found per space: Story Points in company-managed spaces, Story point estimate in team-managed ones, so an epic in one kind of space whose stories live in the other still adds up, and nothing is set up or named.
- One level counts. A story estimated at 5 with sub-tasks at 3 counts as 3, and the 5 is shown as set aside; an admin can make the parent win instead. Never both.
- Unestimated work is named, not counted as zero, and an epic with no estimates shows "—", never 100%.
- On the work item, in the Details column and a panel, with nothing to set up; and in one table across the spaces you choose, each epic a row with points done of total, time and % complete, downloadable as Excel or CSV.
- It runs inside Jira: no servers, read-only. Its totals are not a Jira field, so they cannot be searched with JQL or put on a board card.
