It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Epics don't show up on the product backlog

Using JIRA Agile, I've noticed that epics don't show up on the product backlog in Plan mode. Why is that?

Is it because epics span more than one sprint?

So in order to determine when the last task associated with an epic is scheduled on the backlog, I assume users just look at the highlighted epic field? Is that right?

2 answers

1 accepted

3 votes
Answer accepted

Epics are shown in the left filter panel, next to Versions.

have a look here for common usage

In our shop, epics merely exist as containers for all issues representing the work (story, ...) involved to deliver a certain feature. We also use Epics to group the involved delivery artifacts (code changes, docu, testing,...). So, epic "work" issues are allocated to sprints, while epics can be used to filter the views.

So in order to determine when the last task associated with an epic is scheduled on the backlog...

You can consult this information on the same epic filter panel

Click to expand the epic details, here you can derive number of remaining work/issues left. e.g.

Issues 4
Completed 3
Unestimated 0
Estimate 2d 7h 12m

See for more details on epic completion.

Alternatively, you can

  • use a final work issue within the epic to verify work done & close the epic, etc..
  • look for another way to handle this (e.g. generate a list of .. / scripted solutions to auto-close all epics without any open child issues, ...)

Good luck,


Thanks for your reply Ben. I've seen the Epic filter panel but I would have liked ot see th eepic on the prodict backlog too because we might not know what the tasks (to group together) are at the time we create the epic.

Another question I have which I hope you may be able to answer. When we create an epic we tend to estimate it at 1 hour and then put realistic estimates against the tasks that are associated with that epic. I'm wondering what others do.



I feel the same way as you Ramon. It is a pity that epics without stories do not appear in the backlog as it would be really handy to plan out the medium and long term, at a very rough level, before getting to the point of story decomposition.

Yes, even using workarounds to achieve this is difficult as it is difficult to avoid double accounting estimates at the epic and story level.

We start by Story Point estimating the Epics and then, when its priority reaches front of epic queue we decompose to stories and story point those. We then set an explicit state on the epic that means 'Decomposition complete, ignore my SP estimate and use those of the stories'

Like # people like this

here's one approach on this:
- the only issue type on which a default time estimate makes sense (for us) are "Bug" issues, we default those to 2 hrs, to cover the initial investigation time.
- instead of requiring epics on the backlog, you could use a preceding issue type (e.g. "Analysis", "New Feature", ..) that is used to provide the epic with its contained work breakdown issues (and their respective estimates). The epic itself would not contain the actual work est, but aggregates the contained issues' estimates. When the epic & its contained issues are created, the contained stories can be qualified for sprint readiness ( & included in sprint planning. In a way, we are using 2 parallel processes in each sprint cycle: one preparation process (by PO + analysts who prepare business epics towards readiness) & one delivery process (by the agile team who develop, test, .. towards shippable).

Note that this is just one approach (that has worked well for the type of projects we deal with).
I'm sure there are many other ways possible to deal with this.
Basically, I think it depends heavily on the context in which work is happening.. different project size, complexity, roles involved etc.. could lead to variations of the 'applied' agile approach.

Like Liam likes this

Thanks for the contribution Ben. That's an interesting idea. Just so I understand, the 'preceeding issue type' - does that carry an estimate for the analysis of the Epic or a very rough guess at the magnitude of the epic as a whole? I think the latter is what we are looking for. What do you do with that issue once the Epic and its stories are created and estimated?

BTW We are also modelling the same 'parallel process' and have enabled the concurrent sprint feature so we can see the whole pipeline on an agile board.

Hi Tony,

Preceding issues would indeed contain only estimates for the preparation work.

When the preparation work is done, this issue is closed. Often, since the epic gets created during this prep work, the preceding issue can be moved under the resulting epic (could be useful for time rollup & reporting later).

Typically such a preceding issue (or Epic) would contain a rough estimate of the whole feature (volume & complexity), which can be used in interactions with customer (scope / approval etc..), but we prefer to keep that as separate information & definitely don't use JIRA's native estimation fields for this.

I sympathize wholeheartedly with the frustrations reflected in this thread. Epics should live on the product backlog. There's an open issue for it here:, would be great to see other comments here...

Like # people like this

I also sympathize with the frustrations. Epics should live on the product backlog. 

Many people here probably have a radiator or wall in the office with index cards stuck to them. On that physical wall, you would put an epic or a user story on the wall - no problem. 

The backlog is a place where product managers store things and keep things visible. 

I see the justification above. But I disagree with it. If the goal is to support our workflows, then that goal is not being met.

the UI designer did a good job but the new UX IS TERRIBLE. I am ready to drop this product. 

Like Rikki Prince likes this

Agreed. The app should not treat epics as somehow "special": they're just tickets. it's presumptuous to apportion them an intrinsic special status. If one doesn't want to see them in a given view, then that can be controlled via a filter.

Like Ahik Oron likes this

I agree with my namesake Patrick O'Malley, 2nd of his name. 

Like Carlo Moras likes this

Epics have been a challenging discussion point now in my last two organizations. 

In one, we used Epics (by Product Managers) to describe an entire feature, then broken down into stories (by Lead Developers/Architects) and tasks to execute on said feature.  This method was favored by and provided transparency to the Product teams while providing metrics and levels of accountability across the dev teams.

In this regard, they are special, yet deserving of their own project, backlog and "board" to track overall progress, ideally automatically, based on the aggregated state of the underlying stories. 

All to say I'd like to bring this approach to my new organization; however, I am now required to reimagine our process given the "poor" overall support for Epics.  Unless I am missing something...

Like # people like this

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you