How to create Jira epics and use them the "right" way

[#1]

Creating an Epic in Jira is easy. Creating useful Epics is harder, because there’s no one-size-fits-all Epic structure that works for every Jira team.

But there are some well-established best practices (and a few common anti-patterns) that can help you decide what deserves to be an Epic, how to scope it, and how to keep your Epic structure useful as your projects grow.

What is an Epic in Jira?

An Epic in Jira represents a large body of related work, broken down into smaller child issues like user stories, tasks, and bugs. The hierarchy is: Epic → Story/Task/Bug → Sub-tasks.

Instead of treating related tasks as isolated work, an Epic groups them under a common goal. For example, a new billing experience might include several user stories for design, payment management, and testing. Grouping these related stories under a single Epic gives them purpose and lets you track progress on the larger initiative as one unit.

But there's an important distinction: an Epic is not necessarily a project, product area, team, release, or component. Those things may be related to the Epic, but they serve different purposes.

For example, an epic groups work items by goal, while a release groups work items by what ships together. This means work items from the same epic can land in different releases. Your “User Authentication” epic might have some stories in Release 2.1 and others in Release 2.2, depending on what's ready at that time. So don't try to force all work from an epic into a single release — that would only create unnecessary bottlenecks and delay value delivery.

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.

When to use an Epic (and when not to)

Do use an Epic when:

• The work contributes to a larger outcome you need to track progress on.

• Multiple issues make up the delivery.

• The work is part of the roadmap, and stakeholders need visibility.

• The Epic will span multiple sprints or involve multiple teams.

Don't force an Epic when:

• The work is a standalone, one-off change.

• It's a small fix that doesn't contribute to an existing initiative.

• You'd have to invent a meaningless Epic just to satisfy a process rule. A few unparented issues are better than an instance full of useless epics.

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.

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 unestimated 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: Planyway 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 vs the original estimate, giving you the real data on profitability and team efficiency.

How big should an Epic be?

There's no magic number of story points or sprints that makes something an Epic. A better test is scope and outcome.

• Too Small: "Add password visibility toggle" is likely a story.

• Right-Sized: "Redesign authentication" – This could contain multiple stories, tasks, and design work while representing one outcome.

• Too Broad: "Improve customer experience" – This is closer to a strategic goal that could contain multiple epics.

Epic best practices

1. Give Epics a clear scope
Define the goal, why it matters, what’s in and out of scope, success criteria, dependencies, and target date. A good Epic should help with planning, not just group issues.

2. Don’t let Epics live forever
“Authentication” shouldn’t stay open for years. That’s a product area, not a delivery outcome. Break it into Epics like “Launch SSO” or “Migrate Auth Service.”

3. Don’t use Epics as categories
Use Epics for things you’re actually delivering. Use Components or Labels for persistent categories like product areas or technologies.

4. Connect work across projects
When an outcome spans Platform, Web, and Mobile projects, use the Epic to connect the work. Then bring those projects into one view to see the full delivery plan.

5. Plan capacity, not just scope
An Epic might contain 240 hours of work, but that doesn’t mean the team has 240 hours available. Plan the work against actual team capacity to spot overload early.

6. Watch for scope creep
Epics grow one issue at a time. If an Epic starts covering several unrelated outcomes, split it into smaller, focused Epics.

The right way to think about Jira Epics

Don’t create Epics just to keep Jira organized. Create them because they make the work easier to plan and understand.

A good Epic tells you what the team is trying to deliver, what work belongs to it, and whether you’re making progress. It shouldn’t stay open forever or become a catch-all for everything related to a product area.

And as your work starts to span multiple projects, teams, and people, you may need more than Jira’s built-in Epic views to see how everything fits together. That’s where tools like Planyway can help you turn your Epics into an actual delivery plan.

[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.

[Mary from Planyway]

@Michael Rankin thanks! fixed