Do multiple levels of epics make sense?

Question

Is it a sensible approach to have multiple levels of epics to structure the requirements of an Agile project?

For example:

• Epic "As a User I want to browse information on a website"
  • Epic "... I want to browse topic A"
    • User-Story "... I want to see Diagrams on topic A"
  • Epic "... I want to browse topic B"
    • User-Story "... I want to see Photos on topic B"

Or is it better to have a 'flat' requirements hierarchy? i.e. only 2 levels of hierarchy, epic -> user story.

Answer 1

I'd slightly rephrase the question as: what's the benefit on having Epics of Epics?

If you have a sound answer that makes perfect sense in your head and you see real value on using it, I wouldn't have much problems about going for it.

Happens that, the idea to keep a single hierarchy is to avoid making it overly complex. What's the criteria to consider something an Epic? And an Epic of Epics? Are you going to open a door to Epic of Epics of Epics?

You must stick to what's best for your project, and in most of the cases, the simpler the better.

I personally would not go for Epics of Epics. There are other ways to gather requirements together (depending on the tool you're using, of course), like Epic Themes. But in my project, we forced ourselves to not have an Epic of Epics explicitly to make sure that the breakdown level we have is clear enough and would make simpler to any new joiner to understand how things work.

Another temptation to use Epic of Epics is to track project performance, but doing so is from my point of view wrong, since you'd be mixing up concepts (capacity management and task tracking).

Answer 2

There exists an additional, often-used, term that can help you here: themes. Themes are collections of stories with a common theme (thus the name).

So you could organise your epics thus:

Epic "As a User I want to browse information on a website"
    Theme"... I want to browse topic A"
        User-Story "... I want to see Diagrams on topic A"
    Theme "... I want to browse topic B"
        User-Story "... I want to see Photos on topic B"

For more information, there is a nice article on the subject at http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes, that succinctly describes a fairly industry-standard way of using epics, themes and stories.

Answer 3

To me multiple levels of User Story (or Epic) makes perfect sense.

I use an analogy of rocks. A really big boulder and a tiny pebble are both still a rock. In the same way, an Epic or Theme is still just a User Story. Using the INVEST principles, a user story should be scalable.

A user story can start as vague as "I want a new finance system" at a very high level, which is valid but obviously too big to fit into a sprint. This may take lots of steps of breaking down before it is a deliverable user story. How you group, prioritise and deliver these is totally up to you.

Personally, I get frustrated by the agile buzzwords of 'Epics' and 'Themes' as they are all just sliced and diced user stories, do it however works for you.

I've also seen a lot of time wasted in organisations arguing over whether something is a user story, and epic, or a theme. Write it down, add it to the pile, and consider it a 'thing to do' that needs some more information. If it's too big for the team, they will quickly identify that and when it is nearing the top of the backlog it is time to split it up.

Answer 4

I've seen multiple levels of Epics used often. I think what David was suggesting is Theme might be useful to prevent confusion.

In many ways, until you have a task that can be done in an 8 hour day, you have an epic. All an Epic is, is a recognition that you already know that this story is so big it will need to be carved up. User stories can and do get carved into sub-stories and all tasks are is really just another breaking of a story.

You might want to pick different names for them, or perhaps do a numbering code so the third story of the first sub-epic of the second epic would be numbers 2.1.3.

Answer 5

An Epic of Epics isn't really necessary or value added. The various levels of detail in Agile planning correspond to specific planning horizons. The hierarchy of planning artifacts is less about decomposition and traceability (common concerns in waterfall specifications) and more about minimizing planning effort and avoiding planning rework.

See this article by Don Wells, which introduces the Planning/Feedback loops concept illustrated in the image below.

Epics exist to capture logically grouped information that is too large for an iteration. Stories exist to capture product capability that can be created within a single iteration or sprint. Tasks exist to capture day-to-day responsibilities. Detail is deferred until it is likely to be used so that plans can change and adapt to customer needs without lots of rework.