How to split a User Story when it is too big?

In my previous post, I described the features of a good User Story. They form an easy to remember abbreviation: INVEST where the letter  ‘S’ stands for ‘Sized Appropriately’. It refers to the User Story’s size which ideally should be limited to fit into one iteration.  In some cases, however, one iteration may not be enough for full implementation. If the User Story exceeds this limit, it should be treated as an Epic and subsequently broken down into smaller chunks.

The main objective when making the division is to have the newly created User Stories deliver value to stakeholders independently from each other. It’s also good to adhere to other features forming the INVEST rule when making the division plan. It is advisable to cut User Stories vertically, in other words, to follow the functionality lines so they may be presented independently to the users.

The so called horizontal split, where the User Story follows the subsequent implementation steps (for example, preparing data structure, business logic implementation and user interface design) should best be avoided. Even worse idea is splitting the User Story following the software development process lines, so for example, having a separate User Story for creating a design, other for implementation and another one for testing.

Correct ways to make the cut

Off course, there are many different ways to correctly split User Story, the only limitation being the level of creativity of the Business Analyst. This post presents several examples on how to make the cut when the User Story turns out to be too big (impossible to implement in one iteration).

For the sake of clarity of this example, I only focus on one element of the User Story: Statement of Value.

Following the process steps

If the process consists of many steps, each of them may be described by a separate User Story. The simple example may be processing an order in an online shop. It may include elements like adding items to the cart, selecting payment method, selecting shipping method, reviewing order summary and placing the order. The entire process may be described as one general User Story:

As a client I want to be able to place an order in an online shop to receive selected items.

This User Story would probably be too complex and time consuming to be implemented during one iteration. However, it could be successfully split into smaller stages following the previously defined process steps:

As a client I want to be able to add items to the cart to indicate what I intend to buy.

As a client I want to be able to select payment method to pay in a preferred way.

As a client I want to be able to select the shipping method to receive my items in a preferred way.

As a client I want to be able to review my order summary to verify the details and avoid any mistakes.

As a client I want to be able to confirm the order and send its final version to the shop to receive ordered items.

Following the acceptance criteria

User Story may contain multiple acceptance criteria. It is then reasonable to split it according to a particular subsets of these criteria.

Continuing in an online shop scenery, let’s imagine a User Story related to placing an order and including multiple acceptance criteria, such as ordering multiple items, ability to edit items in the cart, option to cancel the order (‘empty cart’ feature), displaying cart’s current value, etc. Then it is possible to design User Stories based on excluding particular acceptance criteria.

Following the scope of data

Making a cut following the data scope makes sense when working on User Stories involving processing complex structures or vast amount of data. Let’s look at displaying the user profile in an online shop. It may include user’s name, basic personal or contact details information (name and surname, email address, phone number), multiple shipping addresses, invoice details, preferred payment and shipping methods, etc.

If the User Story related to displaying all available data in the user interface turns out to be too big for one iteration, try to group these data and create a set of independent User Stories, each related to a particular data group.

Following operation types

Typical operation set that may be performed on a given data collection is so called CRUD operations set (Create, Read, Update, Delete). If operations required in your User Story may be grouped according to the CRUD set, then particular type of operations may be separated into independent User Stories. If, for example, an online shop user is required to provide shipping address (or multiple shipping addresses), it is possible to isolate it into a separate User Story related to address handling: displaying, editing, deleting, etc.

Following non-functional requirements

Non-functional requirements do not seem to be a particularly fortunate parameter to become a basis for User Story split. There are many examples to support this statement, however, there are also many cases where it can be done successfully. As an example, let’s analyze the performance requirements. Assuming that a report should be generated in less than 5 seconds (under given circumstances and when processing given amount of data), in this case, one User Story may be dedicated to the report generating process and the other one should aim at process optimization.

Another example may be the availability of user interface in multiple languages or possibility to use the application on different operating systems (e.g. Android, iOS). Each interface language or support for different operating system may be placed in separate User Story.

It is, however, worth noting that placing the non-functional requirements into a separate User Story sometimes proves to be risky. When non-functional requirements are treated independently, the likelihood they will never be implemented increases.

Naturally, there are many other good ideas on how to divide a User Story when it is too big. The ones described in this post represent only few of them and do not exhaust available options.

My recommendations

  • When estimation indicates that the User Story is impossible to be implemented during one iteration, split it
  • Split the User Story along the vertical lines so each of them delivers value independently and may be presented as a separate unit
  • Make sure that User Stories resulting from the splitting process reflect the INVEST features