Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


Please Note: User Stories are not a part of Scrum. User Stories are just one technique among many (Use Cases, Prose requirements, Test Scenarios, etc)to implement Product Backlog Items within Scrum.

Summary

  • Epic- A large User Story, generally too big to fit into a single Sprint.
  • Theme - A collection of related User Stories.
    • 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.
    • This 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, rather than diving into small, fine grained, detailed stories.
  • I walk through an example of Theming in the full article below.
  • I walk through an example of using Releases as Themes in the full article below.
  • Some leading "Agile" ALM tools incorrectly use the term Epic to mean what is really a Theme(collection of related stories). Unfortunate, but true, and probably not that big of a deal in the grand scheme of things.

Intro

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.

Releases as Themes

Some teams uses release as themes, which his sometimes helpful with Release Planning and Release tracking via burndown charts. So, in our example above, we might decided to theme the current stories as follows (stories are listed in priority order)

Story/Epic
Associated Themes
Pay by MasterCard/Visa
Release Feb2011, Credit Card Payments, Online Payments
Pay by American Express
Release Mar2011, Credit Card Payments, Online Payments
Pay by Discover
Credit Card Payments, Online Payments
Pay via PayPal
Online Payments

So, looking above, we know that MasterCard and Visa are targeted for the February 2011 release, Amex is scheduled for the March 2011 release, and the last two stories have not been targeted for any particular release. Since the Epics are listed in priority order, it is perfectly acceptable that we haven't yet scheduled the lower priority Epics for a release. Much like a product backlog, the Epics and Themes near the top of the list are more fine grained(have been broken down further) than the epics and themes near the bottom of the backlog.

At this point, given the theming above, we may decide that we really don't need the "Online Payments" theme any more. At the highest level planning, it was useful because we were considering online payments alongside with other Epics like searching for products and allowing users to post reviews on products. Once we broke the Epics down further into themes with smaller Epics, conveying "online payments" vs. "credit card payments" or "pay via PayPal" didn't provide a whole lot of useful extra information. By now, the Epics have been discussed in planning, and everyone knows that credit cards and PayPal are the online payments we've been discussing As such, at this point I would drop the "online payments" theme because we just don't really need it any more.
So, now we might have our themes as follows:

Story/Epic
Associated Themes
Pay by MasterCard/Visa
Release Feb2011, Credit Card Payments
Pay by American Express
Release Mar2011, Credit Card Payments
Pay by Discover
Credit Card Payments
Pay via PayPal


Wait! How come "Pay via PayPal" doesn't have a theme? Because it doesn't really need one. Let's go back to the definition of Theme - a set of related user stories. We've already said that due to the collaborations that have already occurred, everyone already knows what we mean when we say "Pay via PayPal", so it doesn't really need a theme. Not every story has to have a theme, and themes are generally only useful to external stakeholders and the Product Owner, and generally only highly useful at high level planning like product road mapping and Release Planning.

At this point, we've pretty much used Epic and Theme where it's most useful -- at the road mapping and Release Planning levels. There is one more usage though that might be interesting to some teams.

Let's say your Scrum team is planning to do "Pay by MasterCard/Visa" soon. Because they're doing it soon, they would like to slice the stories into smaller chunks to allow their testers to get a first crack at testing something end to end sooner. The team has decided to slice the story into "Happy/Sad/Bad" paths. The bad paths will represent a story where the user goes all the way through the purchasing process but finds out that the credit card processing system(a 3rd party service) is down. The sad paths will represent cases where the card is rejected for various reasons (over the limit, invalid card, invalid card verification #, etc). The happy path will represent the cases where the card is accepted and the user is able to proceed with their order. The team decides to assign these stories to their related theme "Pay by MasterCard/Visa". So, now the stories and the backlog looks like this:

Story/Epic
Associated Themes
MC/Visa bad paths
Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments
MC/Visa happy paths
Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments
MC/Visa sad paths
Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments
Pay by American Express
Release Mar2011, Credit Card Payments
Pay by Discover
Credit Card Payments
Pay via PayPal


This is a valid use of themes but I find it to be overkill. Here is what I would do instead:

Story/Epic
Associated Themes
Pay by MasterCard/Visa - bad paths
Release Feb2011, Credit Card Payments
Pay by MasterCard/Visa - happy paths
Release Feb2011, Credit Card Payments
Pay by MasterCard/Visa - sad paths
Release Feb2011, Credit Card Payments
Pay by American Express
Release Mar2011, Credit Card Payments
Pay by Discover
Credit Card Payments
Pay via PayPal


So, what I've done is just rename the stories, which I think is more useful than creating themes every time one has a whim to do so. You could even rename them "Pay by MasterCard/Visa part 1", "Pay by MasterCard/Visa part 2", etc. This is why I believe Themes and Epics are really most useful at the PO and stakeholder level when release planning or road mapping. Keep them as high level grouping mechanisms, because that's what they were really meant for. While the Scrum Team is involved at the Release Planning level as well, they will generally not care that much about the Epic and Theme concepts. They still care most about the stories that they'll have to implement the dirty details for.

Prioritizing at the Epic and Theme level

Another way to make Epics and Themes useful is to use them to do high level prioritization with stakeholders. Generally, stakeholders don't want to get into the nitty gritty of small stories. They really only care most at the higher level view. As such, having them help prioritize a fine grained Product Backlog might not be useful, especially if there are huge amount of stories. In these cases, it is useful to discuss Themes and Epics when prioritizing, which will then give the PO useful information with which to prioritize the smaller Sprint sized stories.

This is not to say that discussing small or fine grained stories with stakeholders is altogether bad, just that it might be bad in certain situations. Obviously you'll have to gauge the situation you're in and use the appropriate level of detail for your audience.

coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg