Agile User Stories, Epics and Themes

20 March 2014

Agile teams favor a just-in-time approach to requirements. In place of a lengthy requirements document, we use feature descriptions that are minimally described, progressively refined, and stored in a product backlog.

User stories are the best way I’ve found to capture just enough information about a feature to facilitate a future conversation between the product owner and the team. User stories are descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

User stories typically follow a simple format:

“As a [type of user] I [want/can/am able to/need to/etc.] so that [some reason].” Though that format has its advantages, user stories can be in any format, so long as the conversations surrounding the stories occur. User stories come in different sizes. A small story, called simply a “user story,” is one that is well understood and can be implemented within a sprint—something like: “As a manager, I want the monthly sales report to be paginated so that I can quickly refer to a specific part of the document.”

Large user stories are typically referred to as epics. There's no magic threshold at which we call a particular story an epic. It just means “big user story.”

Epics generally take more than one or two sprints to develop and test. They are usually broad in scope, short on details, and will commonly need to be split into multiple, smaller stories before the team can work on them.

Building on the monthly sales report analogy, an epic might be: “As a sales manager, I want to see sales broken out by region.”

We call large stories “epics” to communicate something about them. 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. Similarly, 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.

One more term is commonly used when talking about user stories: “theme.” A theme is a collection of related user stories. Let’s say I write a group of stories about monthly reporting that all have to do with formatting. By giving those stories a theme, let’s say “Monthly Report Formatting” we put a virtual (and sometimes literal) rubber band around the stories and can refer to them as a group.

Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme.

Story, epic and theme are merely terms we use to help simplify some discussions Scrum teams have. They have standard meanings that date back to some of the earliest XP teams. And it's nice to use terms in industry-standard ways.

But, you can make up your own if these don’t work for you. Don’t lose sight of the fact, though, that these are just terms, and the most important part of a story is the conversations it creates.

Article Rating

Current rating: 4 (7 ratings)
Comments
Sacha Storz
Dear Mike,

thank you for your feedback. I guess my thoughts were a little "philosophical". :) Semantics... Anyway. Thanks for your reply.
6/2/2014 4:40:47 AM

Mike Cohn
Hi Sacha--
I'm not sure what issue you're getting at with your comment. The product owner is responsible for prioritizing the product backlog. A good product owner knows that also includes listening to the technical team about their priorities.

In general, I'd advise breaking each of the epics in your example into smaller stories and then doing the most important subset of each original epic first.
6/1/2014 12:24:06 PM

Sacha Storz
Sometimes a team tells the PO "This story is way too complex. We need to break it apart." Let's call that a too-big-for-story-epic.

Some other epic is one hierarchically very close to a business objective. "As a sales manager, I want to see sales broken out by region, in order to compare region performance." Let's call that a close-to-business-objective-epic, as my business objective is "Shut down region office performing worst (sorry guys)".

Those two epics might not differ in terms of size/complexity. But talking about and prioritizing those too with business people are two very different things. I would appreciate your thoughts on that.
6/1/2014 7:58:24 AM

Mike Cohn
Hi Shailaja--
Yes, I think acceptance criteria on user stories do the same job as you say. I don't think I can answer how to use use-case elements in user stories because I don't use use-case elements in stories. (If I did, they'd be use cases, not stories.)

However, I think this article of mine on The Advantages of User Stories (over Use Cases) may have what you're looking for: http://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-for-requirements
4/20/2014 10:19:07 PM

Shailaja Sharma
Recently, I had a discussion with a team member about use case elements like triggers, post condition precondition and their preference of those over acceptance criteria. To me acceptance criteria does the same job as pre/post condition and triggers. What is your take on the using the use-case elements in user stories. And how best to use them in that case. Appreciate your feedback.
4/18/2014 5:06:27 PM

Leave comment



 Security code