Mike Cohn's Blog

Stories, Epics and Themes

I’ve been getting more and more emails lately from people confused about the difference between “user story”, “epic” and “theme.” So I thought his month we’d return and cover some basic–but very helpful–territory by explaining those terms. First, the terms don’t matter that much. These are not terms with important specific meanings like “pointer” to a programmer or “collateralized debt obligation” to whomever it is that’s important. Story, epic and theme are merely terms we use to help simplify some discussions teams have. The terms do have standard meanings that date back to some of the earliest Extreme Programming (XP) teams. And it’s nice to use terms in industry-standard ways. But, if these terms didn’t exist, you’d make up your own.

So let’s see what each means.

A user story is simply something a user wants. Stories are more than just text written on an index card but for our purposes here, just think of user story as a bit of text saying something like “Paginate the monthly sales report” or “Change tax calculations on invoices.” Many teams have learned the benefits of writing user stories in the form of “As a I <want/can/need/etc. some goal> so that .” But it is not necessary that a user story be written that way. The advantages of that format are covered elsewhere on this site.

An epic is a large user story. There’s no magic threshold at which we call a particular story an epic. It just means “big user story.” I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There’s probably some car chases, probably some shooting, and so on. It tells you this even though there is no universal definition that we’ve agreed to follow and that an action-adventure movie must contain at least 3 car chases, at least 45 bullets must be shot, and …

So, “epic” is just a label we apply to a large story. Calling a story an epic can sometimes convey additional meaning. Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn’t get the chance to break most of them down into stories that are probably small enough to implement directly.

Finally, “theme” is a collection of stories. We could put a rubber band around that group of stories I wrote about monthly reporting and we’d call that a “theme.” Sometimes it’s helpful to think about a group of stories so we have a term for that. Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme or grouping.

Hopefully you’ve found this short explanation helpful. I look forward to your thoughts.

About the Author

Mike Cohn is the founder of Mountain Goat Software, a process and project management consultancy that specializes in helping companies adopt and improve their use of Agile processes and techniques. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is also a co-founder and current board member of the Scrum Alliance. He can be reached at mike@mountaingoatsoftware.com

31 Comments:

Vikram Kapoor said…

Good stuff Mike. Simple but crystal clear. Only thing I wonder about is why can’t call a bunch of user stories just a theme and thus skip the epic part. As epic is nothing else but big (thus a bunch) of user story. But maybe it is just my weird way of thinking!

Mike Cohn said…

Thanks, Vikram. You’re right that an epic may equal a theme. However, they serve different purposes. We may write an epic as a placeholder for great big features we want to add someday but don’t want to make the time investment in today of creating small stories. For example, back when Amazon was “Earth’s Biggest Bookstore,” Jeff Bezos probably had a backlog item like, “As an Amazon customer, I also want to order CDs so that I can buy CDs at the same place I buy books online.” Once Amazon was ready to tackle that they split it into lots of smaller stories. So epics can serve the purpose of being big placeholders on a backlog. That’s actually an important function.

Neil said…

I use labels or tags on my stories to collect them into themes. Sometimes my stories can belong to more than one theme. A theme might be the collection of stories useful to sales users or the collection of stories from the London users or the collection of stories needed to replace a legacy system. I use epic stories to remind me about the big, hairy audacious stories that someone has asked for but that the product owner has deferred until some other day so we don’t want to peek inside just yet.

Phil Ruse said…

This suggests that it’s possible for a theme to be a collection of stories that originated from different epics?

Sree said…

Thanks Mike for great explanation. One question, what is the purpose of theme? Does themes are assigned to a sprint? Where does themes really help?

RJT said…

I find the most useful conversations with stakeholders are at a scenario (or acceptance criteria) level - ‘given this context, when I do this, the system does that’ ... concrete, unambiguous, simple.

Stories allow me to lump together related scenarios, themes allow me to lump together related stories ... its an organisation mechanism useful for planning purposes.

Epics come into play when we take a more top down approach and want to talk about system behaviour at a more abstract level.

Not sure I’ve added anything to the conversation here! ha ... but thought I’d share my perspective in case its of interest to some.

Mike Cohn said…

Hi Phil—
Yes, it’s possible to have a theme that originated from different epics. (I’m feeling the urge right now to draw some Venn diagrams. :)  For example, let’s stick with Jeff Bezos writing stories back when Amazon only sold books. He may have written the epic, “As an Amazon customer, I also want to buy gardening equipment from Amazon” or “As an Amazon customer, I want to buy car tires and wheels.” He could then have split those into stories. He’d have themes like “gardening equipment” and “tires and wheels” but he might also have a theme like “New Shipping Challenges” because shipping sharp gardening equipment and shipping heavy tires and wheels presented unique challenges to how the items were inventories, packed or shipped. So a theme is any grouping of stories that might be helpful. “High priority bugs” could be a theme. So could “Quick revenue producing stories.”

Mike Cohn said…

Hi Neil—
That’s a great example of some uses of themes. I, too, use tags. I use a todo system for my personal sprints. It’s called THings from www.culturedcode.com and has a great system for tagging each todo item I add. I’ve often thought that a multi-user version of Things would make a great product backlog tool because of the strength of the tagging model within it.

Mike Cohn said…

Thanks, Sree. Themes serve the purpose of grouping together a set of related stories. Let’s stick with my ongoing Amazon example. Back in the early days, Jeff Bezos writes, “As an Amazon customer I want to buy barbecues on Amazon.” He thinks that epic is a great idea so he turns it into a bunch of small stories. However, his team says, “Jeff, you’re nuts! Barbecues on Amazon! No way. We’ve just started selling CDs.” So, he agrees to take those stories he’s written about selling barbecues and put a rubber band around them and stick them back in the shoebox in which they store all their stories.

The advantage of grouping them that way is that they now really only take one up slot in our memory. I have to think “group of barbecue stories” when I see that rubber-banded group rather than having to think about each item. This is an advantage because backlogs that become too big (more than about 150 items, in my experience) are unwieldy and hard to work with.

Mike Cohn said…

Hi RJT—
I think your description that epics are more helpful when planning top-down is a good one. Themes are created bottom-up; epics come from top-down planning is a great way to explain the difference. Thanks.

Catherine said…

It seems that i have a totally different feeling about those 3 terms. I do agree that Epic and Theme are equal some cases. Personally I haven’t use Epic in word before, but I use it every application when looking back.

Russell said…

The terms Theme, Epic and Story can come in handy when trying to deal with the system-software development world of complexity. Using themes, epics and story helps us manage complexity, to simplify and abstract essential aspects of a system by collectively dealing with the parts of the same functionality to satisfy requirements.

We could just as easily used the label Level1 for theme), Level2 for epic, and level3 for story.

Here is an example of where abstracting essential aspects of a system comes in handy.

Mobile phone

Theme – Dialer

Epics – Groups, Favorites

Stories – New groups, rename group, erase group

Theme – Contacts

Epics – New contact, Erase, Options

Stories – Save contact, erase single contact, erase all contacts


How about using a Word processor as an example

Theme - As a User I want to be able to compose, edit and format my composition

Epics – As a User I want to be able to format text styles

Stories – 1) As a User I want to be able to select a word and specify that it is italics 2) As a User I want to be able to select a word and specify it be underlined, etc.

Mike Cohn said…

Hi Russell—
You seem to be proposing that there is a hierarchy between Theme and Epic. That’s not the case. A Theme is not larger than an Epic. A Theme is a collection of stories. An Epic is a large story. A Theme could be bigger than an Epic but an Epic could be bigger than a Theme (e.g., if the theme were of small stories).

Russell said…

Folks struggle all the time with communicating, managing and understanding the context of the system under consideration, understanding the collaboration required to achieve the system’s desired goals, and understanding how function is distributed to achieve system goals within a set of constraints. The use of theme as I suggested serves us well as a grouping mechanism that helps decompose and thus simplify and abstract essential aspects of a system by collectively dealing with the parts of the same functionality to satisfy requirements.

Andy said…

Great recap on Epics, Stories and Themes. But where I see most confusion is when “Features” are discussed (particularly with the rise of BDD).

I see Features as describing the capability of the software, while Stories describe their use to achieve a user goal. Does that match with your understanding?

Mike Cohn said…

Thanks, Andy. I avoid using the term “Features” in any formal way. I’ve seen lots of other people offer other definitions for it so it gets confusing. I try to stick with the terms as used by the early XP teams and explained to me by Kent Beck.

Heiko said…

ah - my favorite topic :)

I think themes are an “orthogonal” grouping mechanism to the epic->story hierarchy - like you can use tags in blogs or to tag your files on your computer.

One thing that always puzzles me. I never manage to work with two level of hierarchy (epic->story). For me it is totally natural to start with a big epic. Sometimes in the project I will split them up into stories. But some of them I will decompose further. So I end up with more then two levels of hierarchy. I wonder if other people find only two hierarchy levels hindering?

Heiko

Mike Cohn said…

Hi Heiko—
The terms “epic” and “story” aren’t meant to imply only two levels. We can have a really big epic that is split into multiple epics. Those epics can again be split into epics and then…. and then eventually split into stories.

You’re right, though, that “theme” is orthogonal to this.

Pawel Brodzinski said…

By the way: recently I heard neat way of naming epic stories which are just very big—a saga. It may be a theme although not necessarily. It’s just an epic which is very big :)

Marc Bless said…

Thanks for clarifying this, Mike. There are lots of people thinking of an epic->theme->story hierarchy rather than taking the orthogonal point of viewing themes.

One of the teams I coach came to a nice item in their definition-of-done for User Stories: as long as a card’s Story Points are greater than 8, it’s considered to be an epic. This really helps to the team to break down things and not commit to big backlog items.

Marc

Mike Cohn said…

Thanks, Marc.

Many teams make a decision that any story above X points is too big and needs to be split before being brought into an iteration. Normally a good size for a rule like that is any story that is equal to about half a team’s velocity. Any story that would be half of a sprint is likely too big to be a good story in an iteration.

Terry Wiegmann said…

Is anyone using themes for roadmap and release planning, e.g., the theme for the next release will be shipping CDs, the theme for the release after that will be shipping big things like BBQs and tractors? Then when the time comes, the stories and epics related to the theme for the next release will be addressed?

Bruce Onder said…

Hi Pawel,

Sagas also refer to long-running processes or orchestrated workflows.  As with many English words, it can easily get confusing as people use them to mean different things in different contexts.

However, that’s the nature of the language.  Nothing to do about it, other than point out when disambiguation is needed. :)

Darren Mews said…

I use Epics to break down the System into Subsystems (matching the Work Breakdown Structure) and I do EVM at Epic Level.  I then use Themes (Feature Groups in VersionOne) to group stories from all the Epics that do a similar thing, e.g.  HANDLE_SYSTEM_RESET.  This approach is working well although tracking progress of Themes has not been as useful as tracking progress at Epic level.

Mike Cohn said…

Hi Darren—
This sounds like a good approach to me.

Scott Withrow said…

After reading through this blog and followup comments, one issue with learning Agile and/or Lean becomes clear. The terminology is not fixed in stone. The difference between Epics, Themes and Stories can be gray intangible concepts applicable differently in different environments. What does appear tangible is the Relationships between the terms. It was really helpful to learn for example that in one case an Epic can be larger than a Theme and in another instance just the reverse. It appears that the one hard concept is the Story with its acceptance criteria. If I understand correctly the other two are methods of categorizing stories into larger logical units. In transitioning to the role of Scrum Master from traditional Waterfall PM, this has been a challange. The fluid nature of Agile is one that takes a little getting used to. Thanks for your posts.

Mike Cohn said…

Hi Scott—
I think you’re right and it’s quite unfortunate. In general I try to use the terms that are in existence rather than create new ones. I was told these terms from Kent Beck and believe they date back to the early XP teams so I’ve tried to consistently use only them. Others bring in other terms like “feature” and try to make things just too complicated.

And you’re right, both themes and epics are just ways of working with larger logical units to keep things simpler.

Wolfgang Göbl said…

Hi,

have you ever thought naming “Themes” -> Use Cases?
This would be an important step in bridging the gap between the agile and the requirements engineering community!

According to Ivar 1992 a use case helps “an actor to achieve a complete business goal”. Which makes a whole lot of sense for being the top level structure of the system specification. The granularity of “Themes” is not well defined leading to problems in practice!

We have very good experiances with using use cases as the top level structure and detailing them top-down to as much detail as makes sense (starting with “casual use cases” as Alistair suggests.

Greetings from vienna
Wolfgang

Mike Cohn said…

Hi Wolfgang—

That’s an interesting suggestion but I’ve never thought of it. I didn’t make up the term “theme” for a group of user stories. I learned it from Kent Beck before I wrote User Stories Applied. I’m not big on changing existing vocabulary—that’s what creates the confusion. Unfortunately others have introduced different terms and made it all more difficult than it needs to be.

Wolfgang Göbl said…

Hi Mike,

today I read Ivars new ideas on use cases 2.0.

http://www.ivarjacobson.com/use_case2.0_ebook/

For me this is the perfect missing glue between the agile and the requirements engineering community.

In my understandig the “use case slices” presented are in competition with the concept of user stories. For me use cases (incl. slices) are a better approach for professional requirements engineering in agile projects because they are better in keeping the overview of the system. Sure - in the agile world we have Themes, Epics but the concepts behind them a too lean for professional RE.

What is your opinion on this topic?

Wolfgang

Mike Cohn said…

Hi Wolfgang—

I don’t have an opinion on this as I haven’t read that book. It sounds like a step in the right direction for use-cases though so I will read it. It sounds a bit similar to Constantine’s Essential Use Case concept. Thanks for the pointer.

Leave a Comment: