+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 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

BTW, I think JIRA Agile (as of v6.3.0.2) has Epics implemented reasonably. They have their own backlog with sequential priority and they don't show up in the Story backlog. I'd just like to see a more 'dense' view, where I could see the Sprint sequencing, or at least progress bars, for several Epics at a time, without having to expand and contract them one-by-one.

I'm not sure I agree with the Description for this issue. In my experience, Themes are comprised of Epics and Epics are comprised of Stories. Finally, Stories are comprised of tasks. Here's one link which supports my understanding: http://wiki.servicenow.com/index.php?title=Themes,_Epics,_Stories,_and_Tasks_in_Scrum.

The Scaled Agile Framework (http://scaledagileframework.com/) has a similar hierarchy. Though they've introduced another artifact called a Feature.

That being said, I'd really like to see JIRA Agile support arbitrary levels of hierarchy with each level having it's own planning and status boards. That way, I could prioritize at the Epic level, for example, without implying that all Stories within the Epic must be completed before starting on the stories in the next Epic. I should be able to have multiple Epics, Themes, etc underway in parallel and they likely will span many Sprints and, possibly, many releases. Rally supports this type of compartmentalized planning: http://www.rallydev.com/toolkits/scale-agile-safely-rally.