Jira epic % complete by points and by issue count

You want each epic’s % complete as a number: how many of its work items are done, and how much of its estimate. People ask for “% complete for every epic based on how many issues are done vs total” and for “a more accurate story point roll up based on story points rather than how many stories were completed”. The two answers differ, often a lot: an epic with one 13-point story done and two 2-point stories open is 76% done by points and 33% by count. This page says where Jira shows progress by itself, gives the Automation rule that writes both percentages into fields, then what Sumline does.

What Jira does by itself

The epic’s child work items show a % done by how many children are done. It is not a field: Atlassian declined to turn it into one you can search, export or report on (JRACLOUD-80273, “Won’t Do”, August 2024).
The timeline’s progress bar shows each epic’s children by status category (done, in progress, to do), “including subtasks” (Atlassian). It counts work items, not points, and only children in the epic’s own space (Atlassian).
The Epic report, on company-managed Scrum boards only, shows an epic’s complete, incomplete and unestimated work by story points or by count, with done meaning the board’s last column (Atlassian).
Plans, on Jira Premium and Enterprise, has both: progress by work item count, which looks only at the level directly beneath (Atlassian), and progress by story points or days, which takes estimates from every level below and shows how many work items are unestimated (Atlassian).

On Free and Standard, nothing on the epic says “76% by points” as a number you can sort or export.

The Automation rule

Atlassian publishes the two formulas (knowledge base): each counts the children in the Done status category and divides by the total. Put them in a rule that runs when a child moves:

Create two number fields, say Done % by count and Done % by points, and add them to your epics.
Trigger: Work item transitioned.
Condition: Work item fields condition → Issue Type is one of → Story, Task, Bug.
Branch: Branch rule / related work items → Parent.
Inside the branch, Lookup work items with the JQL parent = {{issue.key}}.

Inside the branch, Edit work item, setting Done % by count to

{{#=}}ROUND((0+{{#lookupIssues}}{{#if(equals(status.statusCategory.name,"Done"))}}1+{{/}}{{/}}0)/{{lookupIssues.size|0}}*100,0){{/}}

and Done % by points to

{{#=}}ROUND((0+{{#lookupIssues}}{{#if(equals(status.statusCategory.name,"Done"))}}{{Story points|0}}+{{/}}{{/}}0)/{{lookupIssues.Story points.sum|0}}*100,0){{/}}

In a team-managed space, write Story point estimate in place of Story points, in both places. If points change after work has started, add a second rule with the same steps on “Field value changed → Story Points”.

Where it stops:

Direct children only. The lookup finds the epic’s stories, not their subtasks; counting those needs another lookup or rule.
Nothing to divide by. An epic with no children, or none with points, has no meaningful percentage, and the field cannot tell “not started” from “not estimated”.
Unestimated stories count as nothing in the points formula, and nothing says which ones they are.
It runs only when its trigger does. A story moved to another epic leaves both epics’ numbers as they were, and existing epics stay empty until one of their children moves.
A lookup returns at most 100 work items (Atlassian), and every run counts toward your site’s Automation usage.

With Sumline

Sumline is our app. It shows both percentages on every epic without a rule or a field:

% complete two ways, always both. By estimate: story points done ÷ total, or, with no points, time spent ÷ (spent + remaining). By issue count: across all levels below the parent, subtasks included.
An empty epic shows “—”, never 100%, and unestimated children are named.
“Done” follows Jira’s status category. Status names are never used, so renamed and custom workflows count correctly.
One row per epic in a table per space or across the spaces you choose, with both percentages side by side: sort it, filter it by status, assignee or sprint, and export it to CSV. The same rows go on a dashboard gadget.

What it does not do: Sumline only reads, so its percentages are not a Jira field you can search with JQL. How each one is worked out is in How the numbers are calculated.