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