5

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.

Improve this question
1
  • Define "sensible" and "better". What problem(s) are you trying to solve by introducing a multi-level hierarchy? Which project stakeholders get value out of the hierarchy?
    – WBW
    Commented Mar 24, 2015 at 18:57

5 Answers 5

Reset to default
6

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

Improve this answer
3

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.

Improve this answer
1
  • Thanks for the article. So you recommend against more than one level of epics? My understanding of themes is that they shouldn´t be used as hierarchical elements and serve as labels for US with similar attributes (e.g. 'HR Department')
    – perelin
    Commented Mar 23, 2015 at 13:03
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.

Improve this answer
2

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.

Improve this answer
2

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.

Planning/Feedback loops credit: Don Wells / Wikicommons

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.