The Complete Guide to Jira Epics: From Definition to Execution

[#1]

Imagine dumping a bucket of 5,000 mixed Lego bricks onto the floor and telling your team: "Build the Death Star".

No instructions. No sorting by color or size. Just pure, unadulterated chaos.

That is exactly what a project looks like without structure and this is where the Jira Epic comes in.

In this guide, we will cover the standard Jira epic definition, break down the confusion between Jira epic vs story vs task, and walk you through the technical steps of how to create an epic in Jira.

Let's dive in.

What is an Epic in Jira? (Jira Epic definition)

A Jira Epic is essentially a large body of work that represents a significant deliverable. 

Think of it this way: User Stories are for your development team. Epics are for your stakeholders.

Your developers need to know exactly which API endpoint to update (the Story). Your CEO does not care about the API endpoint. They care about "Launching the mobile app" (the Epic).

Why not just use Stories instead?

You might be thinking, "Why complicate things? Can't I just have a list of tasks?"

You can, but you will regret it. Here is why you need Epics:

• You can't put "Update CSS on button" on a quarterly roadmap. It’s too granular. Epics allow you to visualize progress on a timeline that actually makes sense to management.
• Grouping related tasks helps you find things.
• An Epic creates a boundary. If a stakeholder asks for a new feature, you can ask: "Does this help us complete the Mobile Launch Epic?" If the answer is no, it goes in the backlog for later. It gives you the power to say “No” with data.

Jira Epic hierarchy

To master the Jira Epic hierarchy, you just need to memorize these four levels.

1. The Initiative (grandparent)

This sits at the very top. Initiatives represent massive strategic goals that span across multiple teams and multiple projects.

• Note: You won’t see this in standard Jira. You generally need Jira Premium (Advanced Roadmaps/Plans). If you are a small team, ignore this. You don't need it yet.

2. The Epic (parent)

This is the highest level in standard Jira. As we defined earlier, this is your big deliverable. It is the parent container for your stories.

3. The Story / Task / Bug (child)

This is the standard unit of work.

• Story: end-user value ("As a user, I want to login").
• Task: technical work ("Configure AWS server").
• Bug: something is broken ("Login button returns 404").
  All three of these live at the same hierarchical level. They are siblings.

4. The Subtask (grandchild)

This is the grunt work. If a specific Story is complex, you break it down into Subtasks. Use these sparingly. If you have 20 subtasks on one story, your story is too big. Split the story.

Why parent-child relationships matter?

The relationship between an Epic and a Story is a strict parent-child relationship.

When you link a Story to an Epic, you are telling Jira: "This Story contributes to the progress of this Epic".

This is why reports work. When you mark a Story as "Done", the progress bar on the Epic automatically inches forward. If you break this relationship—or if you try to link an Epic to another Epic (which isn't possible in standard Jira)—the logic falls apart.

Stick to the structure: Epics hold Stories. Stories hold Subtasks. Don't get creative here.

Jira Epic vs. Story vs. Task

This is the most common point of confusion for new agile teams. We often see backlogs where everything is an Epic, or conversely, massive projects crammed into a single User Story.

To master the Jira epic vs story vs task distinction, you have to look at scope and value.

• The Epic delivers a collection of value. It is a strategic goal. It solves a big problem.
• The User Story delivers a specific piece of value. It solves a small part of that big problem for the end-user.
• The Task delivers technical execution. It’s stuff the user will never see but needs to happen to make the software work.

If you find yourself carrying a User Story over for 4 sprints in a row, stop. That is not a Story; that is an Epic masquerading as a Story. Convert it.

For a quick reference, here is the breakdown:

The golden rule:

An Epic is "finished" when all its child Stories and Tasks are marked Done. A Story is "finished" when the code works and the user can use it.

Jira Feature vs. Epic

If you are frantically searching through Jira’s settings looking for the "Feature" issue type, you can stop. You won't find it.

This is where the term Jira Feature vs Epic gets messy. In out-of-the-box Jira Software, "Feature" does not exist. It is a concept, not a button.

However, if you work in a massive enterprise organization, you might see "Features" appearing in your hierarchy. This usually happens because your company is using SAFe (Scaled Agile Framework) or Jira Align.

In standard Agile, "Epic" is the big container. But in Scaled Agile (SAFe), the definitions shift to accommodate massive portfolios.

• Standard Jira: Epic > Story.
• Scaled Agile (SAFe): Epic > Feature > Story.

In this advanced setup, the Epic becomes a massive corporate initiative (like "Move entire infrastructure to Cloud") that might take a year. The Feature becomes what we traditional users would call an Epic (like "Build the Login Page").

It is confusing, and quite frankly, often unnecessary for 90% of teams.

My Advice? Stick to Epics.

Unless you have a certified "Release Train Engineer" breathing down your neck telling you to use SAFe, ignore the term "Feature" as a specific Jira issue type.

For most teams, "Feature" and "Epic" are synonyms. We say, "We are building a new Feature," and we track it in Jira as an "Epic".

How to create an Epic in Jira

One of the "charms" of Jira is that there are usually five different ways to do the exact same thing. Creating an Epic is no exception.

Depending on whether you are a visual planner or a list-maker, you can choose the method that fits your brain. Here is how to create an epic in Jira without getting a headache.

Method 1: "Create" button 

This is the global method. It works from anywhere in the application.

1. Click the Create button in the top navigation bar.
2. Ensure you are in the correct Project (it’s easy to accidentally create tickets in the wrong board).
3. Click the "Issue Type" dropdown and select Epic. 
4. Give it a Summary (Name).
5. Hit Create.

Method 2: Timeline view

If you are using Jira Cloud, you likely have a Timeline or Roadmap tab on the left sidebar. This is the fastest way to plan.

1. Click Timeline on the left sidebar.
2. You will see a Gantt-chart style view.
3. Click the + (Plus) icon in the logical column or simply type into the "Create Epic" bar at the bottom of the list.
4. Drag the bar to set the start and due dates immediately.

Method 3: Backlog panel 

If you are organizing a backlog, you don't want to leave the screen.

1. Go to your Backlog.
2. Look for the "Epics" toggle or panel. In Scrum boards, this is usually a switch labeled "EPICS" on the vertical text near the top left.
3. Open the panel and click Create Epic.
4. Type the name and hit Enter. Done.

How to add issues to your Epic

An Epic without stories is just an empty shell. You need to fill it.

• From the Epic: open the Epic issue > Click "Add a child issue" > Type your tasks.
• From the Backlog: this is the easiest way. Open the "Epics" panel we mentioned in Method 3. Simply drag and drop your existing stories from the backlog onto the Epic name in the sidebar.
• From the Issue: open any specific Story > Find the "Parent" or "Epic Link" field > Search for your Epic's name.

Managing Epics: editing and deleting

Creating Epics is the fun part—it feels like new beginnings. Managing them is the chores part.

If you don't maintain your Epics, your Jira instance becomes a graveyard of good intentions. You will end up with 50 Epics labeled "In Progress," spanning back to 2019. This ruins your reports (which we will cover next).

When to close an Epic

An Epic is not a permanent fixture. It has a beginning, a middle, and an end.

• The definition of Done: an Epic is finished when every single user story linked to it is marked "Done".
• The status: when the work is complete, move the Epic status to Done. Do not leave it in "In Progress" just because you might add a feature later. If you add a feature later, create a Phase 2 Epic. Close the book on Phase 1.

How to delete an Epic in Jira

Sometimes, plans change. Maybe the project was cancelled, or you created a duplicate by mistake. You need to nuke it.

Here is exactly how to delete an epic in Jira, but first, a very important warning.

⚠️ STOP AND READ: what happens to the stories?
A common panic attack among Jira admins is: "If I delete the Epic, will I delete all the user stories inside it?"

The answer: no.

In standard Jira, deleting an Epic does not delete the child issues. It simply unlinks them. Your Stories, Tasks, and Bugs will remain in the backlog, but their "Epic Link" field will become empty. They will be orphans, but they will still be alive.

The steps to delete:

1. Navigate to the Epic you want to remove.
2. Look for the three dots icon (...) in the top right corner of the issue view (this is the Actions menu).
3. Select Delete from the dropdown menu.
4. Confirm the deletion in the pop-up warning.

If you actually do want to delete the stories inside the Epic as well, you should go to the Advanced Search (JQL), search for "Epic Link" = JRA-123 (replace with your key), "Bulk Change" all those issues to delete them, and then delete the Epic.

The Jira Epic report to track progress

You have built the Epic. You have filled it with stories. You have assigned the work. Now comes the inevitable question from management:

"Are we there yet?"

Instead of answering "Soon" (which makes you look evasive), you should answer with data. This is where the Jira epic report comes in. Reporting allows you to move from simply doing the work to analyzing how the work is going.

Here are the three main ways to track an Epic.

1. The standard Epic report

This is the classic view for Scrum teams. It gives you a snapshot of completion based on story points or issue count.

• How to find it: go to your Project > Click Reports on the left sidebar > Select Epic Report.
• What it shows: it lists every completed, uncompleted, and un-estimated issue within that Epic.
• Why use it: it is perfect for spotting bottlenecks. If your Epic has 20 stories and 15 of them are unassigned or unestimated, this report will flag that lack of planning immediately.

2. The Epic burndown chart

If the Epic Report is a "Snapshot," the Burndown Chart is a movie. It shows you the history of your progress.

• How to read it: You want the line to go down.
  • The vertical axis is the amount of work (Story Points).
  • The horizontal axis is Time (Sprints).
• The forecast: based on your team's past velocity, Jira will project a grey line into the future, predicting exactly how many sprints it will take to hit zero.
• The "Scope Creep" detector: If you see the bottom of the chart suddenly drop lower (adding more work), you can visually prove to stakeholders that the release date is slipping because they kept adding requirements.

3. The roadmap + resource view by Planyway 

Standard Jira reports have one major blind spot: resources.
Jira can tell you what needs to be done, but it’s terrible at telling you who has the time to do it. If you need to map your Epics against actual team capacity, you likely need an app like Planyway.

• Visual roadmap: instead of the basic Jira timeline, Planyway lets you visualize Epics on a drag-and-drop Gantt chart, grouped by user, epic, or project. You can see instantly if an Epic is blocked because your Lead Developer is double-booked.
• Resource planning: this bridges the gap between the "Epic" and the "Human." You can drag issues from an Epic directly onto a team member’s calendar, ensuring you aren't assigning a 50-hour Epic to someone who only has 10 hours available.
• Time tracking reports: while standard Jira tracks status, Planyway tracks hours. You can pull a report to see exactly how many hours were spent on an Epic versus the original estimate, giving you the real data on profitability and team efficiency.

4 best practices for Jira Epics

Just because you can create an Epic doesn't mean you always should. 

To avoid the mess, follow these five best practices.

1. Naming short and punchy

An Epic usually has two name fields: "Summary" and "Epic Name."

• The Summary appears in the list view. It can be descriptive (e.g., "Integration of Stripe Payment Gateway for Q4").
• The Epic Name appears on the little colored "lozenge" or tag on your story cards.

Keep the Epic Name short. If you name it "Refactoring the entire backend database structure," the tag will look like Refactoring the ent... on your board.

2. Size matters (the 3-month rule)

An Epic should generally fit within a fiscal quarter.
If an Epic takes 9 months to complete, that isn't an Epic; it’s a lifestyle. It’s too big to track effectively, and your team will lose motivation because the progress bar never seems to move.

3. Don't overuse them

Not every story needs a parent Epic.
If you have a random bug (e.g., "Fix typo on About Us page"), just create a standalone Task or Bug. Creating an Epic called "Miscellaneous Bug Fixes" is a common anti-pattern. It becomes a junk drawer where tasks go to die.
Only create an Epic if there is a clear beginning, end, and specific value being delivered.

4. Update the status (please)

There is nothing sadder than an Epic marked "In Progress" that hasn't been touched since 2021.

When you finish an Epic, mark it Done. This removes it from the "Epics" panel in your backlog, decluttering your view for the next big project.

Frequently Asked Questions (FAQ)

You’ve got the basics down, but Jira has a habit of throwing curveballs. Here are the answers to the three questions we get asked most often.

Q: Can an Epic belong to another Epic in Jira?

A: In standard Jira Software? No.
Jira’s default hierarchy ends at user stories. You cannot nest Epics inside Epics (e.g., Parent Epic > Child Epic). If you need a layer above Epics, such as "Initiatives" or "Legends," you need to upgrade to Jira Premium (Advanced Roadmaps/Plans) or use an add-on like Structure. Don't try to fake it using "Link Issue" types; it breaks your reporting logic.

Q: How do I change a Task to an Epic?

A: It happens to the best of us: You created a "Task," realized it’s actually a massive project, and need to upgrade it.
Do not delete it!

1. Open the Task.
2. Click the More button (three dots ...) in the top right.
3. Select Move.
4. In the wizard that appears, change the Issue Type from Task to Epic.
5. Warning: You will be asked to fill in an "Epic Name" since Tasks don't have that field.

Q: What is the difference between Scrum and Kanban Epics?

A: Technically, the Issue Type is identical. An Epic is an Epic.
The difference lies in how you visualize them on the board.

• Scrum Epics: these represent goals targeted for specific releases or versions. You usually view them in the "Backlog" side panel to assign stories to sprints.
• Kanban Epics: these represent a continuous flow of value. In Kanban, you usually track Epics by their status column (To Do > In Progress > Done) rather than by sprint assignment.

[Michael Rankin]

The first item in the best practices section (Naming short and punchy) is out of date.  The lozenge uses the Summary and not the Epic name.  In fact, I don't think the Epic name is used at all anywhere.