How to Track Epic Progress in Jira (Without Being Misled by Percent Complete)

What an epic represents

An epic is a container for a body of work too large for one sprint: a feature, a migration, a customer commitment. In Jira it groups stories, tasks and bugs through the Epic Link field (company-managed projects) or the Parent field (team-managed projects and current Jira Cloud). Above epics, some organisations group work into initiatives using Advanced Roadmaps’ Parent Link or a custom field.

Epic progress answers one question: of the work currently known to belong to this epic, how much is finished? It is a statement about the *whole epic*, across every sprint it has touched. It is not the same as how much of the epic moved in the current sprint — that is sprint work, a different number that should always be labelled separately.

Why epic progress matters — and why it misleads

Leaders use epic progress to decide whether a commitment is on track, whether to add people, and what to tell customers. A misleading number drives wrong decisions in all three.

Percent complete misleads because its denominator moves. If an epic had 47 issues and 29 are done, it is 62% complete. If ten more issues are discovered next sprint and the team completes six, it is 35 of 57 — 61%. The team delivered steadily, yet the percentage fell. Read alone, “61%, down from 62%” sounds like a stall. See epic scope creep.

Percent complete is only meaningful next to the scope it is a percentage of.

How to calculate epic progress from Jira

1. Export the epic’s issues (a filter such as `"Epic Link" = PROJ-12` or `parent = PROJ-12`) with Status, Story Points and Resolution.
2. Exclude sub-tasks — they are part of their parent story and would count the same work twice.
3. Exclude issues in statuses that mean “removed from scope” — Scope Removed, Cancelled, Won’t Do, Duplicate, Not Needed, whatever your workflow calls them. They are neither delivered nor remaining, so they belong in neither side of the fraction. List them separately instead.
4. Map each status to a stage (Not started, Development, Review, Testing, Blocked, Ready for release, Done). Unmapped statuses should be shown as “Other”, never silently counted as done.
5. Divide completed by total, once in issues and once in points.

Issue progress       = completed issues ÷ total issues in current scope
Story point progress = completed points ÷ total points in current scope
Remaining            = total − completed

Issue progress vs story-point progress

Report both. Issue progress treats a one-line copy change and a week-long integration as equal. Point progress weights by estimate, but unestimated issues count as zero, and epics often carry a tail of small, unestimated bugs. When the two numbers diverge sharply — say 62% by issues and 40% by points — the big items are the ones still open. Neither number is more accurate by default; together they describe the shape of what remains.

Done is not Released

“Done” and “in production” are different milestones. An issue can be development-complete, reviewed and tested — done by the team’s workflow — and still be waiting for a deployment window, a release train or a change-approval board. Report two numbers:

Engineering completion % = (Done + Released) ÷ in-scope issues
Production release %     = Released ÷ in-scope issues

Decide which statuses mean *released* (Deployed, Production, Live — whatever your workflow uses) and which mean *done but not yet released* (Closed, Ready for Release). An epic at 92% engineering-complete and 64% released has a release backlog, not an engineering backlog; reporting only one number either hides that queue or makes finished engineering look unfinished. If your workflow has no released status at all, say that production release is unknown rather than showing 0%.

Status distribution

A progress percentage says nothing about *where* the remaining work is. A status distribution does. “29 Done, 8 Testing, 5 Development, 3 Code Review, 2 Not started” describes an epic whose work is mostly built and waiting to be validated — a very different situation from “29 Done, 18 Not started”, even though both are 62% complete.

How to interpret the numbers

• High progress with lots in Testing or Review means the remaining work is built but queued downstream. Finishing it is a flow problem, not a capacity problem. See engineering bottlenecks.
• Flat progress with a growing issue count means scope is being discovered or added as fast as work completes.
• Flat progress with a flat issue count is a genuine stall: little is completing. Look at epic carryover and at what else the team was working on — see engineering investment allocation.
• Large gaps between issue and point progress mean a few big items dominate the remaining work.

Limitations

A standard Jira CSV export describes the *current* state: which epic each issue belongs to today and its status today. It does not say when issues joined the epic, so historical scope — and therefore any trend in progress — cannot be reconstructed from it. Historical scope needs Epic Link or Parent change history. Honest tools say “unavailable” rather than drawing a trend from current membership.

Common mistakes

• Reporting percent complete without scope. Always pair it with total issues and how that total has changed.
• Counting sub-tasks. They double-count their parent story.
• Counting removed work as done. Many workflows map Won’t Do or Scope Removed to a Done status; counted as scope, it inflates progress with work that was never delivered.
• Counting removed work as remaining. The opposite mistake: a “Descoped” status left open makes the epic look further from done than it is.
• Mixing sprint numbers and epic numbers. “14 issues this sprint, 62% overall” is two different measures; label both.
• Treating points as hours. A 62% point progress is not 62% of the time.
• Using epic progress to judge individuals. It describes a body of work, not anyone’s performance.

Leadership implications and questions to ask

When presenting epic progress to stakeholders, show three things together: percent complete, current scope (and how it has changed), and where the remaining work sits. That turns a single number into a forecast conversation.

Questions worth asking

• How much has the epic’s scope changed since we committed to it?
• Is the remaining work not started, or built and waiting in review or testing?
• How much of each sprint went to this epic, versus other initiatives, bugs and support?
• Are the same issues carrying over sprint after sprint?

Example

An Application Workflow epic shows 29 of 47 issues done: 62%. By points it is 103 of 164: 63%. Its status distribution is 29 Done, 8 Testing, 5 Development, 3 Code Review, 2 Not started. Seventeen of the eighteen open issues have already been started, and eleven are downstream of development.

The conversation that follows is not “why is the team at 62%?” but “what is holding eleven built issues in review and testing?” — a question with an answer.

Related metrics and how the Epic Delivery report helps

See it on your own data in the Epic delivery report.

Related guides: epic burn-up charts, epic scope creep, epic carryover and Jira epic reporting.

Completed is not the same as removed

Leaders need to tell apart work that was delivered from work that was intentionally removed. Both leave the “remaining” pile, but only one is progress. Report removed work on its own line — “Scope Removed: 8 issues” — rather than folding it into completed (which flatters the epic) or leaving it in scope (which understates it). Which statuses mean “removed” is a team decision; make it explicitly and apply it to sprint and epic numbers alike.

The Epic Delivery report calculates issue and story-point progress for every epic from a Jira CSV, excludes sub-tasks and any statuses you choose to exclude from scope (listing them separately by status), shows the status distribution with every issue one click away, and keeps sprint work and whole-epic progress in separate, labelled columns. Statuses can be re-mapped in place. Everything runs in your browser.

Checking what is behind the percentage

Click an epic to expand the list of issues its progress is calculated from: key, summary, type, status, assignee, priority, points, sprint, created and last updated. Filter by status, issue type, assignee or sprint, and sort by key, status, assignee, points or last update. The list states how many issues it shows and how many count toward progress. Won’t Do issues are listed but marked as excluded, and sub-tasks are shown on request. The list and the percentage therefore always reconcile. Once you enter your Jira site address, each key opens the issue in Jira.

Frequently asked questions

How do I see epic progress in Jira?

Filter issues by Epic Link or Parent, exclude sub-tasks and issues in statuses that mean removed from scope (such as Scope Removed or Won’t Do), and divide completed by total — in issues and in story points. Show the status distribution alongside it.

Why did my epic’s percent complete go down?

Usually because scope grew faster than work completed. Completed work can rise every sprint while the percentage falls if new issues keep joining the epic. A burn-up chart shows both.

What is the difference between Done and Released for an epic?

Done means development-complete per the team’s workflow; Released means deployed to production. Report engineering completion ((Done + Released) ÷ scope) and production release (Released ÷ scope) separately, so a release backlog is visible.

Should epic progress use story points or issue count?

Both. They answer slightly different questions, and a large gap between them tells you whether big or small items remain.

How do I see which issues make up an epic’s progress?

List the epic’s issues with their status, marking those that do not count (sub-tasks, Won’t Do). In the Epic Delivery report, click an epic to expand exactly that list, filterable by status, type, assignee and sprint.

Related guides

• Epic burn-up charts

  What an epic burn-up chart shows, why it beats a single percent-complete number, how to build one from Jira history, and how to read changing scope without mistaking it for slow delivery.

• Epic scope creep

  How epic scope grows, why percent complete can fall while engineering delivers, how to tell a delivery slowdown from scope growth using Jira history, and what to do about it.

• Jira epic reporting

  How to build a high-level Jira epic report that combines progress, scope growth, sprint investment, carryover, WIP and delivery flow — and avoids the two most misleading conclusions in initiative reporting.

• Epic carryover

  Epic-level carryover explained: sprint carryover by epic, recurring WIP, carryover age, why the same issues repeatedly carrying matters, and the questions engineering leaders should ask.