Concept: Epics and Themes
Epics are single, large stories that usually represent complex requirements that need to be broken down before development. Themes are collections of user stories that are grouped together for prioritization and planning purposes.
Relationships
Main Description

A user story is a brief description of a system requirement from a user's perspective. It can be defined at a high level and decomposed as needed into smaller stories. User stories need to be independent of each other and right-sized to allow them to be prioritized, estimated, and taken on by team members to be developed in a short time. Throughout the development lifecycle, user stories are allowed to be big, then broken down and detailed for estimation and development, but also grouped together for prioritization in the longer time frame.

In the following sections, we introduce epics and themes as ways to represent and group user stories. See [COH04] for additional information.

Epics

Epics are single, large stories that usually represent complex requirements not ready to be partitioned yet, either because they are of low priority and will be partitioned later in the development lifecycle, or because there hasn't been a conversation between stakeholders and the development team to better understand those stories. It is common that, early in the lifecycle, there are many epics, encompassing high-level product features requested by stakeholders. As the conversation evolves, many smaller stories originate from those epics.

The following is an example of an epic:

As a bank customer, I want to use an ATM to perform my banking activities.

This is epic in scope, because the development required seems to be as big as a complete ATM system. This might represent the first request that the stakeholder ever made to the team. It is too complex to be estimated and too big to be finished in an iteration or cycle. It corresponds to the work of a whole team through various iterations or cycles to complete an entire product release. In short, this large story does not possess some of the characteristics of the INVEST Model (Independent, Negotiable, Valuable, Estimable, Small, Testable).

The epic in this example could be broken down into stories such as these examples:

As a bank customer, I want to use an ATM to pay my bills.

As a bank customer, I want to use an ATM so I can withdraw cash.

However, those two stories still seem to be epics, because they are still complex to estimate and too big to finish in a short time frame. Ideally, they should be further broken down into more granular user stories. Let's take, for example, the epic related to paying bills, and break it down:

As an ATM user, I want to use my debit card to pay my electricity bill.

As an ATM user, I want to schedule recurring automatic payments for my cable company bill.

As an ATM user, I want to use my debit card to pay my VISA credit card bill.

Notice that by defining a more specific user role (ATM user rather than bank customer) and providing different usage scenarios (different bill types, specific vendors or providers), it is possible to write more granular user stories that are in better shape to be discussed with stakeholders, prioritized, estimated, and developed in a short time frame.

For more information, see Breaking Down User Stories.

Themes

The process of breaking down larger stories into smaller ones helps the team and stakeholders better discuss their details, prioritize them, and have the team estimate and develop those stories in a short time box, such as an iteration. However, for the purposes of prioritizing stories along a longer time span, such as a release time frame (many weeks to a few months), the prioritization of many fine-grained stories is a difficult process. Therefore, it may make the stories easier for stakeholders to follow if you group shorter ones into collections, perhaps according to those that will have more business value if they are developed simultaneously. It may help the development team to also define what stories go well together, such as stories that have common infrastructure needs or address a common set of features.

These collections of user stories are referred to as themes. A simple analogy is to think of a pack of index cards that represent stories, all bundled together by a rubber band. This provides the flexibility needed for stakeholders and the team to decide to add or remove stories from the pack as appropriate for prioritization and development purposes. A given theme can also be split in more sub-themes as needed, with the option of sub-themes being of higher priority than others.

In the previous ATM application example, these are examples of major themes to use to group stories together:

  • Bill Payment
  • Cash Withdrawal
  • Money Transfer

For the purposes of prioritization along a release time frame, that grouping should be enough. However, for the purposes of more refined prioritization, stakeholders and teams may decide to break a theme down into smaller sub-themes. For example, the Bill Payment theme can be broken down into the following sub-themes:

  • Bill Payment with Debit Card
  • Bill Payment with Scheduled Payments

For more information, see Prioritizing User Stories.

More Information