Guideline: Breaking Down User Stories
This guideline explains how to split user stories for the purposes of prioritization and development.
Relationships
Main Description

User stories may be of different sizes during a project lifecycle, including very large ones that are often called epics. When a user story is close to being implemented, it needs to be right-sized to facilitate being prioritized, estimated, and developed within a reasonable time frame (typically within a time box, such as an iteration). Even if a user story fits within the defined time box, it might still need to be split because it does not fit within the available time to finish.

The sections that follow introduce approaches to breaking down stories for planning, estimating, and development purposes. For details, see [COH06].

Breaking down user stories across data boundaries

One approach is to break down user stories across data boundaries. Look for the data that needs to be supported by the user story. If the data is complex or a large set of inputs will be required from the user or to presented to the user as output, split the stories according to subsets of that data. If there are different types of values, for example default values as opposed to values that can be defined by a user during the operation, then split stories according to those value types.

For example, in the ATM system, an ATM user should be able to make payments for predefined payees that have business relationships with the user's bank. ATM users should also be able to make payments to payees that they add when they authorize payments. In this example, the user story that starts:

As an ATM user, I want to pay a bill....

This use story can be broken down into two smaller user stories, such as:

As an ATM user, I want to make a payment a predefined payee.

As an ATM user, I want to make a payment to a new payee.

Breaking down user stories on operational boundaries

Look for different operations in a user story as a way to split it. From the example on the previous section, adding a new payee and actually making the payment are two separate user stories. This is a possible way to split this user story:

As an ATM user, I want to define a new payee.

As an ATM user, I want to make a payment to the payee that I defined.

Another common way to partition user stories along operational boundaries is to look for the typical operations of creating, reading, updating, and deleting data (CRUD).

Breaking down user stories on system-wide or nonfunctional concerns

There are some requirements to an application that can be considered system-wide requirements, meaning that they apply to many user stories. Examples are security, language support, and logging. There are also nonfunctional requirements that apply to one or more user stories, such as performance or availability.

If a user story is too big to fit into an iteration, split the story into two stories: one that does not include the nonfunctional concern and the other that does. This helps you implement the story in its simplest case (even though you might not want to release the user story without elements of security or performance until they are implemented on a second round).

Breaking down user stories of mixed priority

Some user stories can be broken down based on priority, according to when the parts need to be implemented. In this way, you can start implementing the most important parts first, then add the lower-priority functionality later.

In the ATM example where an ATM user wants to withdraw cash from her bank account, the team might decide to break this story down and develop the common path first, which is to have the ATM dispense $20 bills (U.S. currency example). Another story to be developed later might be to provide the option for users to select cash in $5, $10, or $20 bills.

What is not a recommended breakdown

It is not uncommon that a large user story is difficult to split, even after considering those approaches. However, one thing to avoid is breaking down a user story based on horizontal slices of the system layers. A user story, as small as it could be, still needs to be of value to a user role. Therefore, avoid developing a story that has only user interface elements and no logic or data access. Also, avoid fully implementing the data access without having user interface elements and logic to access that data.

When developing a user story, make sure that you are slicing the various layers of the system vertically, which means that you develop a little bit of each layer to support that user story (for example, user interface, business logic, and data access).