What's an epic in JIRA

The Difference Between Jira Epics and Components

The best thing to remember when contacting JIRA is that the tool was originally introduced as a bug tracking system.


A component is a software / hardware component that can be shared by teams, departments, or across the company.

By tagging your stories with a component, formal release management units can see exactly which components will be put on a UKDT (deployment ticket) or release registration when you use them.


  • SecureSphere
  • MongoDB
  • Hashicorp Vault
  • Wordpress
  • Chrome 54.X.
  • Business objects
  • Oracle X.

Benefits of good component management

By tagging your user stories with components, you can also support detailed reports from Jira

This report tells you which Active Directory stories are blocked in your project. However, you can theoretically expand this search query to multiple components or multiple projects to get really insightful portfolio / system / program reports that support stakeholders, business decisions, or even obstacles.

You can then also break down your product versions for the version (1.0, 1.1, 2.8, etc.) by component to see what is included in each version.

As a ScrumMaster, you can set a filter to display components by owner and determine whether the same developers are grouped around the same components. This heat map then forms the basis for the mutual qualification of the team. Is it very easy to tell the Product Owner and / or the team?

Paul is always working on the Terraform stories. He made 18 out of 19 stories. I would like to suggest a cross-skilling session to the team, but delivery may suffer in the short term as we lose half a day. Can you manage your stakeholders while we are doing this?


Epics are probably one of the most ambiguous terms in the agile community. In my experience, very few teams use themes, so anything larger than a user story is simply subsumed under the heading "Epic".

The official guide from Jira is

An epic captures a great work. It is essentially a large user story that can be broken down into several smaller stories. It can take several sprints to finish an epic. An epic can have more than one project if the board that the epic belongs to contains multiple projects.

Mike Cohn also says the following

A scrum epic is a great user story. There is no magical threshold at which we refer to a particular story as an epic. It just means "great user story". So "Epic" is just a label that we use on a big story. Calling a story an epic can sometimes add extra meaning. Suppose you asked me if I had time yesterday to write the user stories about the monthly reporting portion of the system. "Yes," I reply, "but they're mostly epics." That tells you that while I was writing them, I haven't had the opportunity to break most of them down into stories that are likely small enough to put into practice right away.

Examples of epics

  • Provide the payment API for all accepted payment methods
  • Create a web application firewall
  • Develop the new sandbox
  • Anti-malware capability
  • Install and configure the IDS

Benefits of Good Epic Management

While it is important to start deploying working software as soon as possible, it is equally important to plan your product effectively.

Epics are the first building block for creating coherent and credible roadmaps. By putting the Epic skeleton in Jira first, you can then build your Jira backlog in a logical way, showing stakeholders which epics will be the focus for the next 4 to 12 weeks and which feature packages will be provided later in the roadmap.

You will also benefit from the accuracy of the above reporting. When a stakeholder asks

When is the web application firewall done?

You can quickly say that we estimate the WAF to have around 25 user stories, 6 of which have been completed. If you think the WAF is the top priority, we may be able to deliver it in X sprints / weeks based on our estimates / capacity planning.

Also, if you (like me) subscribe to the average size of user stories for estimation, you can quickly tell people how long each epic will be (within reasonable limits) once the majority of user stories are filled.

Last; If you are a ScrumMaster or BA, by regularly reviewing the epics, your Product Owner can control precisely which areas are less well defined and require significant work to be filled with stories.