Epics vs Themes

epic vs themeThere seems to be some confusion in the Agile world about the difference between Epics and Themes. At the Agile101 blog, Tara Hamilton-Whitaker, a certified scrum master, admits “People often (myself included!) get confused about the difference between Agile Themes, Epics and User Stories.” She then goes on to define them, and a healthy discussion ensues, with someone pointing out that she’s exactly reversed the definitions of Epics and Themes as defined by Mike Cohn of Mountain Goat Software. I was asked about the difference last week, epic vs theme, and my answer wasn’t crisp.

Epic

An Epic is a large story that cannot be completed in a single sprint. For example, you may set yourself a goal for ranking high for a particular term. This can be rewritten as a user story. “As an evaluator of Agile project management tools, I want to perform a Google/Bing search of the phrase ‘agile project management tools’ so that I can identify and research potential candidate products”. There are many tasks that you might execute in order to fulfill this story (and goal), but it’s unlikely that you would be able to rank in the top 3 results for this search term in a 2-4 week Sprint.

Some marketing effects take time, more time than we have available in a Sprint. Time is the distinguishing characteristic of Epics. If you write a user story that has a singular goal, and that goal takes an extended time to realize, then the user story is an Epic. For example, if you write a user story around increasing awareness of certain brand attributes, you’re not likely to accomplish this in 2-4 weeks.

Theme

A Theme is a group of user stories that share a common attribute, and for convenience they are grouped together. The individual user stories, however, can each be accomplished in a single sprint. For example, you might have three different user stories that are all PR activities. They share a common channel of communication, and can be grouped together as a Theme. Each of the user stories has a different end goal and acceptance criteria. They may have different audiences. They could not be written as a single user story. They are not an Epic.

If you think of traditional marketing functions, like PR, advertising, analyst relations, content marketing, etc, and you group user stories by these functions, they will almost certainly be themes. Also, a particular user story can belong to more than one theme, but not to multiple epics. For example, if you’re creating a piece of content and also doing some PR around that content, it could easily belong to both the content marketing and the PR theme.

Where Is the Confusion?

If that seems fairly straightforward, you may wonder where the confusion lies. Confusion arises for one of two reasons: first, in the mistaken attempt to create a hierarchy of Themes, Epics and User Stories and second, in the belief that some items can be either an Epic or a Theme. Let’s look at each of these in turn.

Is There a Hierarchy?

Again, at the Agile101 blog, Tara Hamilton-Whitaker draws the following hierarchy to illustrate the difference between Epics and Themes:

Hierarchy of themes vs epics

I think this is a mistake. If you are trying to accomplish something like “improve login page usability”, break it down into multiple user stories, each of which has its own acceptance criteria. “Improve login page usability” becomes a theme, not an Epic, because it’s not a user story with a single goal and acceptance criteria. I reserve the term Epic for those user stories which cannot be broken down any further, but simply take time to realize, more time than we have in a single sprint. User stories and Epics are on the same level of the hierarchy because they are the same thing – both are user stories. Epics simply take more time. And a theme is not so much a higher level on the hierarchy, as it is a rubber band around a set of user stories to group them for your convenience.

There is also a tendency to say that some items could be either a theme or a user story. For example, let’s say you’re trying to address what I call “The Buyer’s Journey”. You could write a single user story: “As a buyer of agile project management tools, I want to find appropriate content on your web site for each stage in my buyer’s journey so that at each stage I can make the most informed decision possible for my company”. This story could take several sprints to accomplish, and be classified as an Epic.

I’d recommend a different approach. Break this goal into smaller user stories, each with their own acceptance criteria. For example, “As a buyer of agile project management tools in the initial investigative stage of the buyer’s journey, I want to determine quickly if your product supports my key criteria so that I can create a short list of products to be evaluated.” If you break the buyer’s journey down in this way, you might then group all of those stories under the theme “buyer’s journey”. The advantage to this approach is that you’ll create acceptance criteria that are more specific to each stage of the buyer’s journey.

What do you think? Is my approach in sync with how you define epic vs theme? I’d love to hear from you.

Comments

  1. Intriguing

    • Neil De Odhar, New York, NY says:

      The word “Epic” ought to tell us that it’s broad and wide in scope. Just like an epic saga, or a Cecil B. DeMille epic. An epic movie or story can have several themes. And within those themes can be individual dramatic sequences, or events.

      That’s exactly how it is in IT. An epic, high-level description, consists of several themes, each of which contains many user stories, each of which can have many scenarios that can be built and tested using a variety of test data.

    • I’ve recently wrote a blog post about breaking epics to user stories and breaking them into tasks. It covers their difference, scope and the meaning of “definition of done”. Take a look – it maybe helpfull.

      http://dennis-nerush.blogspot.co.il/2016/07/estimations-in-agile-development-epics.html

  2. Eric Sangerma says:

    Very interesting question that might not always have the same answers. In my case I would actually consider an epic, a project I’m working on, for instance lead generation.
    I believe hubspot is working in a similar fashion where you have an epic (long term as you were mentioning) and this epic will be broken into a multitude of small user stories that can be done during a sprint.
    So I would have the epic on top, the user stories that will make this epic and those could then be grouped into themes.

  3. My two cents… Unfortunately, the term epic is overloaded because the versionone tool uses it as a containment item. Nonetheless, this is the way I tend to think about it…
    1. A theme is derived from the goals stated in an agile charter that is they correspond to large groups of business value that customers can understand.
    2. An epic is a logical container of stories that may be grouped by function feature or any other common criteria the product owner decides upon.
    3. Based upon the above, a theme usually corresponds to one or more epics.
    4. Epics are never executable elements or stories. In a relatively ungroomed state, a story may be especially large and even cover multiple sprints for the purposes of planning a release. Once such a story gets within 2 to 3 sprints, it would likely be split into vertical and distinct stories. But an epic is not a story and the story is not an epic.

    • Marjorie Pries says:

      +1 for me. But it’s all about words, the concepts are the same – there’s a big idea or goal, there are some specific strategies to carry out to achieve the goal, each strategy has a set of tactics that must be executed to succeed. So now I’ve introduced a new taxonomy for this theme-epic-story or epic-theme-story discussion. I find that for me, “theme” is more abstract than “epic” which I instinctively relate to its literary meaning. Literature has several epics where the theme is “getting home”, each of these epics can be pulled apart into individual stories about one thing that happened while trying to get home.

      • Couldn’t agree more, Marjorie. Thanks for the comment

      • I totally agree, Marjorie. I’ve talked to people from several different companies in the past and we all do things basically the same way, but sometimes the words we use to describe what we do are different. As long as everyone working for a particular company use the same terminology, so things don’t get confused, it doesn’t matter.

  4. Oskar Carlstedt says:

    Good post!

    For me a theme is, whole or part of, a larger strategic business goal? A theme doesn’t fit INVEST principles, especially it lacks the definition of done conditions and it’s therefore not measurable in an easy way. In my opinion an epic is more like a large user story that plays with most INVEST principles but needs to be split into smaller user stories, also following INVEST principles, to get planned.

    So as the blog post says, an epic or a story can be part of (or relate) to many themes in such way it brings value to reach the goal set by each theme.

  5. You’re missing the poems.
    Poems are the key to successful development.

    A subterfuge for lack of professionalism,
    lack of ability to concentrate on a subject,
    lack or articulating what do you want,
    lack of following / and even understanding a
    logic explanation concise precise from start to end.

    Everything has a plan, a design, a Boat, a House,
    a Car even Irak invasion, how anyone can think
    you’re making software over poems !

    This is just beyond scrupulosity.

  6. René de Ruyter says:

    It’s an old post I know and things have changed. Terms like initiative and feature have popped up. I am more a Scrum purist and don’t want to focus on User Stories and such, but call everything a Product Backlog Item. In the end you can define any form you like to be used as a Product Backlog Item. Being a User Story, a standard service (like we want to use https), or even a smell of something that we want to recreate (being chemists et al).

    But now hacking into this debate. I like the rubberband metaphore for themes.

    If we take the film industry as analogy, then an EPIC is the thing that brings value, a STORY doesn’t. It is just an seemingly unrelated part that doesn’t help to understand what the movie is about.

    Then themes in movies. You can theme movies, but you can also theme stories of movies (conversation between mother and father) and epics (love resurrects).

    I think theming things up can be helpfull for Product Backlog management. It isnt necessarily benefecial for Sprint work.

    • René thanks for the comment. I’m not a purist on much of anything and if you find it helps your Agile practice to call things product backlog items rather than User Stories, go for it. In Marketing, I find it helpful to write a user story, even if you don’t call it that, because it helps you understand the specific person, what they’re trying to do and why (the benefit). I think this is good discipline. However, many product backlog items may share the same user story, or similar user stories for different personas.
      As far as Epics go, I’ve never found that term particularly helpful. The standard definition is a user story which requires more than one Sprint to finish. Other than encouraging you to break down your work into bite size pieces, I don’t think that definition is very helpful. I find story mapping much more helpful. This helps us map our stories (or backlog items) to specific points in the buyer’s journey.

Trackbacks

  1. Epic vs Theme | Agile Marketing for mHealth | Scoop.it says:

    […] What's the difference between an epic vs a theme? Is there a hierarchy?  […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.