An Epic within an Epic

Question

First off, I believe I have a good understanding of User Story Hierarchy (Epic > Story > Task), but I've had a quick search around and I wasn't able to find a definitive answer to this.

Can you theoretically have an Epic within an Epic. For example, you have a relatively complex feature that could be worthy of its own epic, but in turn forms part of a larger piece of functionality. If so, how would you go about visualising this? If not, I presume I should attempt to re-think the stories involved and how they can be seperated out.

Answer 1

Absolutely! An Epic is just something too big to be done in a single iteration. As you refine it more (it gets closer to the top of the backlog), you may find it is really several epics. At this point you can nest them or break them out into their own Epics and get rid of the original Epic.

More recently we've actually seen the introduction of more informal layers to help prevent confusion. Initiative and Feature are used by a lot of large enterprise companies to do this. An Initiative is above an Epic. It's at the fuzzy strategic level of "we want to offer a completely new service to our existing customers."

Features are placed between Epics and User Stories. Typically 3-4 features make up an Epic. The Feature is then decomposed into the User Story.

End of the day, the only firm thing you need to do is to document your "story hierarchy" and clearly communicate it. Print it out and put it next to your task board or pin it up at people's desks.

Answer 2

You can definitely have an epic within an epic. Call it whatever you will, just make sure that all stakeholders in the project have a clear understanding of whatever hierarchy & definitions you choose to use and what each item is intended to do on the project.

Personally I'm a fan of keeping things as simple as possible and whenever I can, advocate for a two level hierarchy. Epic>Story aka Intangible>Tangible

Epic is anything that is too big to be story point estimated; it extends beyond the tactical time-frame of an iteration and the immediate consideration of the delivery team. A story is something a team can commit to delivering to the customer by the end of the iteration.

As an aside, your main metric (velocity) is based around the story. By keeping the hierarchy as flat as possible and keeping your buckets simple you also reduce the risk of stakeholders trying to use things like tasks, features, epics, milestones, themes, etc to drive a delivery schedule (try to control the cone of uncertainty), measure individual productivity, derive story point to hour conversions, and a handful of other waterfallish-agile things that organizations with lots of management levels love to engage in.

Answer 3

According to the Scrum Guide, Scrum itself does not define what the product backlog contains (it's just some description of the work that needs to be done). Using names like "epics", "features" etc. is pretty common, however you could actually call them whatever you want - the main goal is that is that this serves you well. So yes, you can definitely have an epic in an epic. You could even have an epic in an epic in an epic if you wanted to.