Epics vs Themes
There 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 others. 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 of creating the ultimate guide to your product category, and as you outline this guide, you realize that it cannot possibly be accomplished in a 2-week 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, longer than a single Sprint, then the user story is an Epic.
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 communication (PR) related around a new product. They share a common message, and can be grouped together as a Theme. Each of the user stories has a different end goal and acceptance criteria, maybe a different channel of communication. They may have different audiences. They could not be written as a single user story. They are not an Epic.
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 the same theme, but not the same Epic.
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:
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 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
Pingback: Epic vs Theme | Agile Marketing for mHealth | Scoop.it
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.
Yeah, both Hubspot and MindJet use epic in the sense of long term project. I’d tend to call that a theme, but there’s certainly room for differences.
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.
+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
Hi Jim,
Thank you for these articles they are very insightful. As it regards to marketing plan to launch a Holiday campaign would you agree that Holiday itself is an epic and items such as creating a new landing page to guide the UX, product catalog, creating a new blog post and ect., are stories within this epic or what is your take?
Jesse, sure you could use Epic in that fashion. My only concern with this is that I’ve moved away from doing big bang campaigns, and moved more towards a more iterative approach, where I try out different experiments, learning from each one to improve over time.
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.
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.
Good clarification, Oskar
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.
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.
Well, the confusion might be because epics might mean different things for different teams. Check this article out, it explains the concept and tells how to deal with epics: https://kanbantool.com/blog/how-to-manage-agile-epics-in-kanban-tool