Epics don't show up on the product backlog

[Ramon Padilla]

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?

[BenP · Accepted solution]

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

have a look here for common usage https://confluence.atlassian.com/display/AGILE/Working+with+Epics

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 https://confluence.atlassian.com/display/AGILE/Completing+an+Epic 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,

Ben

[Ramon Padilla]

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.

TIA

Ramon

[Tony Laycock]

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'

[BenP]

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 (http://guide.agilealliance.org/guide/definition-of-ready.html) & 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.

[Tony Laycock]

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.

[BenP]

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.

[Chris Gagne]

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: https://jira.atlassian.com/browse/GHS-8851, would be great to see other comments here...

[Patrick O_Malley]

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.

[Olivia Hydari]

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

[Adam Cameron]

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.

[Tim O'Malley]

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

[Darren Bailey]

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