What is a Jira Epic?

A Jira epic is a large body of work that spans multiple sprints and is broken down into smaller stories, tasks, or bugs that share an Epic Link. Epics represent feature-level outcomes - 'Customer self-service portal' or 'Migrate to Postgres 16' - not single deliverables, and typically span weeks to months.

Category: Agile & Scrum Also called: Epic Issue, Epic-level issue

Short definition

A Jira epic is a large body of work that spans multiple sprints and is broken down into smaller stories, tasks, or bugs that share an Epic Link. Epics represent feature-level outcomes - 'Customer self-service portal' or 'Migrate to Postgres 16' - not single deliverables, and typically span weeks to months.

What an epic represents

A Jira epic is the unit of work above a story. It captures a customer-facing outcome (“New onboarding flow”) or an engineering initiative (“Sunset the legacy authentication service”) that’s too large to finish in a single sprint. The epic exists to give that outcome a single name, a single owner, and a single place to roll up status across the dozens of stories and bugs that deliver it.

Epics are issues like any other - they have a summary, description, assignee, status, and reporter - but they sit at the top of Jira’s default hierarchy: Epic → Story / Task / Bug → Sub-task. Child issues are attached to their epic via the Epic Link field on Data Center, or via the parent field on Cloud (both are exposed the same way in JQL via "Epic Link" = ABC-123 / parent = ABC-123).

When to create an epic vs. just a story

A useful rule of thumb: if completing the work requires more than one sprint, more than one team, or more than about 8 story points, it should probably be an epic. Anything smaller is a story. Many teams also create an epic for any work that needs its own changelog entry or release note - the epic name becomes the “what shipped” headline once it closes.

Epic burndown and reporting

Jira’s Epic Burndown report tracks the cumulative story points of child issues across sprints, projecting when the epic will finish at the team’s current velocity. The report only works if estimates live on the stories, not on the epic itself - which is why epic-level story-point fields should normally be left blank.

For STM Issue Templates users: an epic is the most common place to wire an On Issue Created Executor. Whenever a new story is added under the epic, STM auto-creates the standard QA, documentation, and release-note sub-tasks so the team doesn’t have to remember the boilerplate.

See also (Redmoon products)

Common questions

What is a Jira epic?

A Jira epic is a large body of work that spans multiple sprints and is broken down into smaller stories, tasks, or bugs that share an Epic Link. Epics represent feature-level outcomes - 'Customer self-service portal' or 'Migrate to Postgres 16' - not single deliverables, and typically span weeks to months.

What's the difference between an epic and a story in Jira?

An epic is the parent container; a story is one deliverable slice of it. A story should be completable inside a single sprint by one team; an epic almost never is. If a 'story' keeps slipping across sprints, it's actually an epic in disguise and should be split.

Should a Jira epic have story points?

No. Epics are estimated through the sum of their child stories' points, not their own. Putting story points directly on an epic double-counts work and breaks velocity reporting. Estimate the stories underneath, then let the Epic Burndown report aggregate them.

Can a Jira epic span projects?

On Jira Cloud, yes - epics can be linked to issues in other projects via Issue Links or the cross-project Plans feature. On Jira Data Center the Epic Link is project-scoped by default; cross-project work is usually modelled via Issue Links or Advanced Roadmaps.