nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

BenP

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

All comments

BenP

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

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.

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_pwz24d

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

sprint

epic

plan