still not possible, from 2013? that's a VERY longer-term roadmap indeed!

We absolutely need a better solution to rank EPICs and other Jira Issue Types.... The backlog EPIC tab is painful to find and rank EPICs. There needs to be a better way.

I guess with the announcement that all server products will be discontinued we can stop hoping for this feature.
https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html

Maybe they will move this feature request to their data center backlog.

How many votes do we need. It will help a great deal having the epics being displayed as an issue type in a backlog. 

I agree this would be nice to have.

Another vote. Surprised this wasn't already possible!

Dear Jira Server Product Management team, 

any updates on this one?

Another vote for epics in the backlog.  Would be good in both classic and next gen boards. 

I would also like to be able to see Epics in the backlog.  A conversation with the developers the other day brought up the problem that they don't have a natural idea when to start breaking down the epics as they don't travel up through the backlog.

Please provide this capability. The backlog is so much harder to manage when the epic stories are not included in the backlog. I have duplicated stories and even triplicated stories because I don't see the story in the backlog. We have stories that have partial descriptions and acceptance criteria because they are "lost" to an epic before being completed and then a new story is whipped up later because we forget to look though all of the epics. And since the epics have no search functionality, You literally have to go one by one to see if there is a user story that matches what you are looking to create. Too time consuming to keep up with.

Generally love Jira, but surprised by the many inconsistencies, this issue being one of them. It's strange that I can view epics in a sprint, but not in the backlog. I echo the comments made by others here.

As a planning tool the Board Backlog allows you to prioritize - valuable. 
Epics are great for high level planning because they group stories - so it makes sense to create the Epic and then add stories.
Epic Name is highlighted in Backlog stories - valuable for developers and managers alike.

It would be valuable to me to be able to see and prioritize Epics on the Backlog. 

Seeing Epics in a product backlog is imperative to a product owner who is needing to constantly refine the backlog. An epic might not have user stories yet and as such, will not show up in the product backlog and could be missed. This seems like a pretty fundamental otherwise you might as well just use Tasks and sub-tasks....

This feature of having epics on the backlog would also be useful for me. Can it be delivered next week instead?

Hi everyone,

Thanks for your interest in this issue.
This request is considered a potential addition to our longer-term roadmap.

We'll typically review this request in about 12 months time, at which point we’ll consider whether we need to alter its status.

For the nearest future we've decided to prioritize other areas of the Jira Server roadmap, including:

• Performance and stability improvements
• Optimising the use of custom fields
• Improving performance of boards
• Improving Jira notifications
• Allowing users to edit shared filters and dashboards
• Mobile app for Jira Server

You can learn more about our approach to highly voted server suggestions here.

To learn more on how your suggestions are reviewed, see our updated workflow for server feature suggestions.

Kind regards,
Jira Server Product Management

+1 we are having major issues moving the business side to agile processes because of the very strict way epics are handled. Let users choose how to handle epics board by board please. 

+1 - we need to be able to prioritize features against everything else without having to do a bunch of silly workarounds for something that probably won't require more than 30 minutes of effort to change the filter.  At least give us a "combined" view that shows everything and still allows drag & drop for priority ranking.   

Coming up on the 5 year anniversary for the reporting of this issue. What's the over/under on even getting an indication that this might be approaching the "maybe this year" part of the roadmap?

+1

In a complex product environment many Epics need to be planned over time to achieve product milestones. Epics are an easy way to visual this on the planning board and should be visible in Sprints and in the backlog to help with prioritization and planning.

+1

The ability to "categorize" stories and track them on burndown reports is pretty cool... but the terminology mix-up is very confusing. I'd love Atlassian to come up with a different name for the functionality is already there and add a simple "Epic" type task that would represent what Epics truly are.

+1 Agree, our current workaround is to create an Epic then add a spike story that is associated to the Epic to create the related stories.  However this doesn't seem like the best solution.  Only the stories that are part of the Epic show in the backlog ranking, not the Epic itself.  Maybe an option would be to make the Epic show as a backlog item if no other stories / items are associated to it.

+1

I assume that with all of the new developments in Portfolio for JIRA, this is on someone's radar somewhere. Recent updates with making Team a first-class concept in JIRA make me think that "cleaning this up" is also desirable.

If this is being driven by Portfolio, I'll also point out that Portfolio allows you to set up a custom Hierarchy (i.e. Initiative => Epic => Story). If representing that hierarchy in the JIRA backlog is covered in another feature request somewhere else, it might not be evident here.

Anyone from Atlassian have any further info on this?

We try to use LESS (Huge) with JIRA and not being able to plan epics and put them inside a sprint does not fit well for this approach.

So our workaround will be to use stories only and maybe rename their issue name  to something like "epic story".

+1 I would also like a way to prioritize a Epics and individual Stories (that not related to an existing epic) in a single backlog. 

Sometimes we have one-off work that is just a single story, so it doesn't warrant an Epic.  However, we would like our Product Owners to prioritize these stories in the context of the prioritized list of Epics.  So a consolidated, prioritized backlog consisting of Epics & Stories (that aren't part of a larger Epic) might look like this:

(1 = highest priority, 8 = lowest priority)

1. Epic DEF
2. Epic ABC
3. Story 456
4. Epic GHI
5. Story 789
6. Epic XYZ
7. Epic JKL
8. Story 123

Once a story becomes part of a larger Epic, it would no longer be shown in this view, as it would be prioritized as part of the larger Epic it is a member of.  I can't find a way to accomplish this in JIRA.  The only workaround I can see if creating Epics that consist of one story just so we can prioritize that story amongst the list of Epics.  But an Epic that consists of one story doesn't make much sense.

+1 This may turn to be a major stumbling block in being able to wholly adopt JIRA for our project management.  Epic seems to be the only mechanism to have have 3 levels (Epic -> Issue -> Subtask).  But if the whole thing cannot be configured to be displayed, prioritized, and pulled into a sprint, it limits it's usefulness.

+! from me too!  It's annoying to have to click on EPICs in order to see an EPIC.  Also, what happens when you want to catch an EPIC from going not reviewed!

+1 from me as well, at the moment we need to create an epic, and then a story in that epic just so that we can prioritise this.  Agree with Eric Babinet's solution above.  When an Epic has a story, we don't need to see the Epic on the backlog anymore.

+1, totally agree that this is needed so that Epics can be sized and prioritized on the backlog before they have been broken down into stories. Once an Epic has any stories in it, it should disappear from the backlog.

+1, in agreement with both the issue summary and many of the comments. The current setup is also confusing for team members new(er) to Scrum.

+ 1 I think a fundamental concept of Scrum is that you don't break down Epics into smaller Stories until the Epic gets prioritised close to the top of your product backlog i.e. don't break down requirements into detail too far ahead of time. However you still want to be able to add/see and prioritise those Epics in the backlog continuously. That's what a backlog is!

+1 It would be great to see and prioritize epics in the Backlog view/Plan mode along with the other issues.

+1 Agree with the others

+1 The current way of dealing with epics is not helpful

+1 Would love to see this. Otherwise, epics are just sort of 'hidden' away when being used as somewhat of a 'parent' ticket. 

+1 - not having this blew up my planned workflow for themes to organize epics.     I had not tried to do this since using greenhopper back in the day -https://xkcd.com/1770/ sort of sums it up

+1 We could use this update as well.

+1 from me. My ideal workflow would be to create high level Epics in the backlog, then as the project progresses and we dig into those Epics, we flesh them out with user stories. But it's critical that they be visible in the backlog when prioritizing.

Could this be a valid work around? Use feature work item type when you want to use EPIC for prioritization. Use sub-feature (or whatever customized work item type) to break down work items to schedule-able work items. And link them together. It lost the nice EPIC to work item grouping effect but should still accommodate the different needs for prioritization at monthly or quarterly prioritization (Feature Jira item) vs. weekly work schedule at scrum planning meeting (sub-feature Jira item) .

I'd like to add my vote on this issue. It's standard scrum practice to prioritize and size epics in the product backlog along with other product backlog items. Mike Cohn speaks eloquently about the subject here: https://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

Atlassian has mixed up "Epic" with "Theme" in scrum terms. This is further complicated by the use of theme in Portfolio, though I am willing to forgive that choice more than the appropriation of "Epic".

Any word on this? Would be great to be able to see/prioritize epics in a project for planning purposes!

We are also facing this issue - with a licens for 500 users, you would expect them to be prioritize this up - and deliver... This is screaming to all Scrum Master and Agile coaches!

This description summarizes the issue precisely. Our Org is looking for all kind of wonky work arounds becaues of this. Could you possibly enable it as a "Labs" feature to see Epics in the backlog? Or to distinguish Epics from Themes?

We have the same problem. I think the Jira definition appears to be more theme than epic as well. It may work as designed so doesn't constitute a bug, but let's agree this is more than just a suggestion. It's how it should work based on any scrum model.

So frustrating to continue to see the boilerplate response: "That's not how we designed it, and we don't care if that's what you want or need."

We would also really like to be able to have a "planning" view for epics, it would make it alot easier to provide a high level view of a product roadmap. As it currently stands, we have to create a dummy "Analysis" task for every epic, so we can get a backlog listing of all our full product roadmap. It would be much easier to just have a backlog view of all our epics.

I'm really hoping that this is being acted on. We really need the ability to decompose from epic to story within the same backlog

+1 from my org as well. Our biggest driver is the ability to pre-slot our epics into future iterations and have the story point totals update dynamically as they do in the backlog for stories.

pls make it possible, would help us a lot!
and also to view them inside the sprint
thanks

My organization would also like to see Epics as Backlog items.

Ideally, we want to be able to use velocity to predict release scope where SP estimates are against a mixture of Stories and Epics. At present it is tricky to avoid double accounting as some epics have already been decomposed to child stories and some not.

I have changed this to a Suggestion from a Bug. The current implementation of epics in Scrum boards is working as designed, this Suggestion will track the ability to work with epics in the backlog (as opposed to a separate panel referred above as a 'themes' approach).

Kind regards,
Martin
JIRA Software

I would like to be able to display and rank Epic in backlog so that product owners could do Epic level prioritization.

Scenario: 60+ developers, 8+ product managers, 50+ Epics through the year. Before we do user story level backlog grooming, we need do EPIC level backlog grooming. We were forced to use google sheet to do prioritization of EPICs because the current Jira UI treat EPIC as theme. We need EPIC as a backlog item.

It is confusing that epics are not displayed in the backlog. I'm not sure I would go as far as to say that the concepts are "misused" but there is definitely an improvement to be made here.

I would like to have the possibility of tracking epics in a backlog just as stories. Epics are not themes, as themes never get closed, while epics do have an end of life. Please consider raising the priority of this feature request, because as such I do not think this can be considered a bug (it was meant to work as it does by design).

While practices vary from team to team, I don't see anything preventing users from using a fairly textbook approach to managing epics: as very large stories.

That was always what they originally were, right? There's a story that ends up being too big once it's estimated, so it's broken up into smaller stories, and the original story becomes an epic that's used as context, relating the new stories that came from it. All epics would (1) start as stories, where they can be prioritized and estimated (probably with 40/100/∞ story points, for easily distinguishing epic-worthy stories), and then when the time comes to pull it into planning, the team (2) splits it into smaller stories that can fit into sprints, and the scrummaster (3) edits the original story and changes it into an Epic, finally (4) assigning it to the newly created smaller stories.

I realize there are many other approaches to working with epics and stories, and that won't work for everyone, but it may be worth considering if this method hadn't crossed your mind before.

As Scrum Masters, we need to make continuously updated, cheap and cheerful predictions of the scope that is likely to be delivered on arbitrary release dates in the medium and long term future in order to help the Product Owner make good business decisions across the portfolio.
We have a velocity measurement and have taken the time to do high level story point estimates on the upper portion of our backlog. However, like other commentators, our backlog outside the current sprint is a healthy mixture of un-decomposed Epics and Stories.
At present, Jira Agile's Version Reports and Release Burndown graphs give inaccurate projections as it double accounts the SP estimate on both Epics and their child stories.

I agree wholeheartedly with @Gustavo. A product backlog contains both epics and stories. There are plenty of times where you'll have story-sized work that you're planning on doing AFTER completing an epic or two. For instance, a backlog could easily look like:

Story
Story
Story
EPIC
Story
EPIC
EPIC
Story

Why would stories be prioritized after epics? Perhaps because they were already story-sized at the time they came in but were prioritized after epics. Either way, epics are placeholders for groups of stories but they are still first-class backlog objects.

@Chris, your pointer to https://www.rallydev.com/toolkits/scale-agile-safely-rally is valid, but this is primarily designed to manage Portfolio and Program level planning for companies using SAFe. Notably, they use this to manage the Portfolio and Program backlogs which cross teams. If JIRA were to implement this correctly, then the notion of an Epic using JIRA terminology would be a cross-team artifact. (Also, SAFe is the only approach to Agile at scale that I am aware of that doesn't formally describe teams using Epics. This is because much of that uncertainty is worked out during Release Planning and so doesn't technically hit the team's backlogs.)

I also agree with @Gustavo that ServiceNow is not particularly authoritative on this. If anything, the Scrum Guide is the only real "canon" for Scrum and it doesn't even mention Epics (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog). It does mention, however, that "Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail." This is consistent with Mike Cohn's blog post (that epics are just user stories that haven't been broken down yet but still have priority order in the backlog).

Justification:
http://www.infoq.com/articles/product-backlog
http://www.ibm.com/developerworks/rational/library/user-stories-product-backlog/ (Keep in mind that Dean Leffingwell, who invented SAFe, also commercialized IBM's Rational Unified Process).
http://scaledagileframework.com/team-backlog/ (this shows a feature in a team's backlog, which is bigger than a story but smaller than an epic)
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
My own experience as a product owner and Agile coach (as well as CSPO, CSP, and SAFe-SPC)

@Gustavo

Yes, there are different interpretations of Themes and Epics. I stand by my previous statement that more levels of hierarchy are needed, whatever they are called. Furthermore, at least as of today, I'm satisfied with how GH handles Epics. As I noted, I'd just like the option to view Epic status in a more condensed format.

I don't remember seeing epics and themes being defined like that. I don't know how authoritative ServiceNow.com in in this subject, but I believe the definitions I gave are the generally accepted ones in Scrum. Here's a post by Mike Cohn: http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes