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.
|