User Stories: Epics and Themes


  • Epic- A large User Story, generally too big to fit into a single Sprint.
  • Theme – A set of related User Stories.
  • A story can be associated with one ore more themes.
    • Any story that belongs to more than 2 themes generally is overkill.
  • You can use “Releases” as themes.
  • The terms Epic and Theme are really only most useful during high level planning like road mapping and Release Planning.
    • Which means they are generally most useful to the PO and stakeholders, and less useful to the Development Team.
      • Exception: Using Releases as Themes is generally useful to the Development Team.
    • It is sometimes easier for stakeholders to discuss and help prioritize stories at the Epic and Theme level.
  • I walk through an example in the full article below.


Epics and Themes are useful when communicating at high level road mapping and Release Planning. That is to say, planning on a horizon that is a couple of months to a year or more from now. Because we are planning at the high level, and because the business stakeholders who are involved in such high level planning typically don’t want to get mired in details, Epics and Themes are useful concepts for high level planning. The concepts are also useful for stories that need to be planned and estimated (again, taking a high level view) where not a lot of detail about the stories is readily available.

Epic Defined

Epic – a User Story that is too big to fit into a sprint. Most often, this term is used to describe a very large User Story that will need to be broken down into smaller stories. Epics usually appear at the Release or Backlog Grooming Level. Epics can be useful when planing for a system on a further horizon than Release Planning. Some companies call this “Product Road Mapping” or “Product Visioning”, whereby plans are made to deliver major releases and features(Epics) over the coming year or so. At that high level of planning, you can’t afford to be working with stories that are fine grained(too granular for that level of planning) and small, so speaking in terms of Epics and Themes often helps. Practically speaking, a story is an epic if it is too big to fit into a sprint, OR if it’s unknown as to whether it is too big to fit into a sprint or not.

Theme Defined

Theme – a set of related user stories may belong to one or more themes. For instance, you might have a set of user stories related to administering a system, or a set of user stories that revolve around improving system usability. Conversely, a User Story can belong to one or more themes.
Often times, an Epic can be sliced into several stories. One way to remember that all of these sliced stories is related is to say that they belong to a particular theme.

An Example

Let’s say you have a store where you sell specialty books, the kind you can’t get at any old bookstore. Maybe they’re antique, maybe they’re religious, whatever. You’ve decided that you want to go online. Your first step might be to display some of your more popular books online, and allow people to place an order online. So, folks can add books to their cart, and create an order that gets emailed to your customer service team who then calls the customer for payment and to finish processing the order.
This might work fine for a while and you made some sales that you never would have made had you not gone online. However, sales online are beginning to get quite good and it’s taking a lot of human intervention to call customers and get their payment information. Instead, you decide it’s time to accept credit cards online.

So, you might start with an Epic titled “Pay for order online.” The initial High Level Story Tests(Sometimes called Conditions of Satisfaction or Acceptance Criteria at this high level) might be:
1. Test that customers can pay by Credit Card.
2. Test that customers can pay by Paypal.

That Epic could then be broken down into two stories:
“Pay by credit card”
“Pay via Paypal”
You could then say that each of those stories belongs to the “Online Payments” theme.

At this point, the dev team might say that “Pay by credit card” can’t be done in one sprint, and that “Pay by credit card” will be a much bigger story than “Pay via Paypal.” The PO then gets estimates on each of the stories, and decides, based on maximizing business ROI, that “Pay by credit card” is still the more important story. The PO might then leave “Pay via Paypal” alone for a while because she knows that it will be 2-3 sprints at least before it will be developed. Instead, she focuses on slicing the credit card story into smaller slices, hoping to eventually get to sprint sized stories and get the dev team working on accepting credit cards as soon as possible.

At this point, the PO might break “Pay by Credit Card” into the following stories:
“Pay by MasterCard/Visa”
“Pay by American Express”
“Pay by Discover Card”

One could still say that all of those stories belong to the “online payments” theme. One could also then say that these three stories also belong to the “credit card payments” theme.
This is just one example on how the terms “Epic” and “Theme” can be used. I don’t use the terms highly often at a Sprint level, but sometimes they’re very helpful in high level planning like Release Planning. They’re especially helpful when stories get sliced and then re-prioritized to where stories from the same theme are quite far apart in terms of priority on the Product backlog. Themes also can help the PO decide when to schedule releases of the software. Maybe they want to finish all of the stories in the “credit card payments” theme before they release. Or, maybe they want to break the “credit card payments” theme into a “credit cards phase 1” theme and a “credit cards phase 2”. Maybe phase one is just MasterCard and Visa, while phase two is Amex and Discover.
Themes can be created with any subject or category. All you’re doing with a theme is saying that a set of User Stories is related in some way, and that you want to remember that they are related in that way.

I wouldn’t recommend going overboard with themes, though. Having a story that belongs to one theme is fairly common. Having a story belong to two themes is more rare, but still happens. Having a story belong to 3 themes is probably overkill or at the very least bordering on overkill.

Stay Tuned

In my next post, I will walk through an example of using Releases as Themes and discuss some other ways of using Epics and Themes.


7 Responses

  1. Nice. Helpful

  2. Strongly agree on keeping the board and the sprint backlog in sync. Wished though more tool-support for that in this stone age.

  3. I don’t want to nitpick, I’m new to SCRUM and am a developer. It seems to me that a breakdown of your epic to

    “Pay by MasterCard/Visa”
    “Pay by American Express”
    “Pay by Discover Card”

    would not help a developer team in a real situation. It is the kind of suggestion from a PO that can really frustrate the developer team.

    MasterCard would not be more difficult than American Express. Both would not be much harder then doing just one.

    The complexity in terms of defining the user story are in:
    * Agree on the multiple screens in this single line definition:
    review order -> collect credit card information -> process against 3rd party -> confirmation with some track number
    * Agree on the form that the user needs to collect the data
    * Agree on the behavior in case of a problem.
    missing user information
    required business rule
    failure to process the request with third party
    * Agree on ability to break from flow (go from step to step)

    plus a technical complexity that is hidden from the PO:
    How to make sure data collection is secure
    What information to store, what information must be purged.
    Building with no risk of billing twice because a user click checkout twice, decides to reload page after POST.
    design to prevent CSRF / XSS attacks

    it seems to me that breaking the story to:
    “Pay by MasterCard/Visa”
    “Pay by American Express”
    “Pay by Discover Card”

    would put 85% of the work in the first story. AND get a different form and look and feel for each credit card we add.

    Now both sides are frustrated. PO & Users want at least 1 credit card to work well and be completely shippable. Developers would want to build a simpler problem first. Worst all of this comes up only during the sprint planning, which is quite late in the process.

    • OS,

      Like many things User Story related, how stories are split is a collaboration between the development team and the PO. How to split the stories will be different for every team and every set of requirements.

      For instance, you make this assumption:
      > MasterCard would not be more difficult than American Express. Both would not be much harder then doing just one.

      What if you were using two totally different back end payment processors? I think the effort involved might not be the same.

      Another instance:
      > AND get a different form and look and feel for each credit card we add.

      Not necessarily. They could each have the same look and feel. It just may be that the look and feel part is already built after “Pay by MasterCard”, and then re-used in “Pay By American Express”.

      Now having said all of that, how you split still will depend on every situation. My intention in this article was not to talk about how best to split stories, but to convey the meaning of Epics and Themes. If you would like some story splitting advice, I recommend Richard Lawrence’s tips at:

      One last thing:
      > Worst all of this comes up only during the sprint planning, which is quite late in the process.

      This is a bad smell. Generally speaking, an epic or story should be discussed multiple times before Sprint planning, enough so that there are multiple opportunities for the PO AND Dev team *together to decide* how best to split them. I would hope that before Sprint Planning, at the very least, the stories/epics/themes would have been discussed at a Release Planning Meeting AND during a Backlog Grooming Session. For more info, see my series of articles on backlog grooming here:

      • Thanks for the quick reply 🙂

        The frustration was certainly not intended against your specific post and comes from me trying to read about people experience applying SCRUM in a big project.

        I see it work very well when the entire user story can be discussed end to end and coded in a single sprint.

        I am still uncomfortable with how well it scales to epics where fleshing out stories and plans an iteration at a time can quickly get you revoking UI decisions, use case decisions and design decisions of previous sprints.. and I know its agile but it still exponentially more expensive to catch these problems late.

        I am also a bit of a skeptic because I have never seen ’emergant design’ that is also a good clean design.

        but your specific blog post does not try to tackle these problems, which makes this a bad place to have this conversation.


      • btw I especially like Pattern #3: Major Effort on Richard Lawence’s tips 🙂

  4. No problem OS. I think the biggest smell in all of this is that the PO should work with the dev team well in advance of the Sprint Planning meeting to split Epics and stories. The splitting itself should be a collaboration and shared decision between the PO and dev team. The splitting should never be a decision that is wholly owned by either the PO or the dev team. It is a joint venture and a joint decision.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: