Why Should We Split Up Large User Stories?

User stories are a fantastic tool, we can all agree on that. But it's far too easy to write user stories that are too large. Large stories bring a number of problems, including:

  1. The development effort required to deliver a story is hidden.
  2. They are written at a higher level, and therefore are more vague.
  3. Multiple features are encapsulated into a single story.
  4. They don't demonstrate the value of smaller functions.
  5. Acceptance critera becomes a way of including more functionality, rather than as a tool to prove the story was delivered correctly.

However, fear not! There are many methods we can use to attempt to split a user story up into multiple (and more valuable) smaller stories.

Vague Story

As a user,
I want to amend my order,
so that I can inform you of any changes I want to make before you deliver my order.

The above story is quite vague. What exactly does amend mean? The customer may be able to amend multiple different aspects of their order. Some of these may be more important than others.

As a user,
I want to amend the CRD date of my order,
so that I can request for my circuit to be delivered at a later date.


As a user,
I want to be able to amend the site contact for my order,
so that you have the most up to date contact details for any site visits.

We now have two stories, which we can both prioritise and explain the value of separately. But not only that, we are also giving the delivery team greater flexibility to deliver one or both of the stories depending on their ability to deliver within a single sprint/development cycle.

Complex Story

As a customer,
I want to order FTTP,
so that I can get high-speed internet access.

The order journey is extremely complex, there is little chance of delivering it all in one story, However, we can attempt to split this story up by the separate aspects of the workflow. What does the user have to do in order to place an order?

As a customer,
I want to choose an FTTP usage limit,
so that I can pay for a product in line with my usage


As a customer,
I want to check if I can order FTTP using my CLI,
so I don't go through the order process if I cannot get FTTP.


As a customer,
I want to check if I can order FTTP using my postcode,
so that I can check if a premise can access FTTP before I occupy it.


As a customer,
I want to pay by direct debit,
so I don’t have to worry about remembering to pay you every month


As a customer,
I want to pay by debit card,
so I can manage payments myself.

Those are just a few of the stories from the user perspective, as you can see we are splitting the large story up into its component pieces, that can each be delivered separately. Not only that, but we may choose to delay some of the less important stories to a later phase too, as they may not form our view of a minimum viable product.

Conjunctions

It's really easy to use conjunctions in a user story, but we should try to stay away from it. Words like "or", "and, or "it" mean we are clumping multiple features into the same story.

As a customer,
I want to pay by credit card or PayPal,
so that I can purchase an item.

For most of the reasons mentioned above, we should definitely split this story up into its independent functions.

As a customer,
I want to pay by credit card,
so that I can purchase an item.


As a customer,
I want to pay by PayPal,
so that I can purchase an item without giving you my card details.

Subjective

Subjective words are a developers worst nightmare. Works like "easily" and "quickly" all mean different things to different people, and the chances the stakeholder and the developer have the same perspective is very small.

As a customer,
I want to place an order quickly,
so that I don’t have to spend a lot of time on your website.

The above story can mean many different things, so it's better to be explicit.

As a customer,
I want to skip the registration process when placing an order,
so that there are less steps I have to go through before submitting.


As a customer,
I want you to populate my address after providing my postcode,
so that I don’t have to enter my address manually.

The above stories make clear exactly what the requirement is, the developer doesn't have to guess what the user really wants.

Acceptance Criteria

One of the issues with large user stories is that we revert to encapsulating requirements into the acceptance criteria of a story. This isn't good for anyone.

As a user,
I want to receive updates to my order,
so that I know how my order is progressing.

AC1: Does the user receive an email when the order is accepted?
AC2: Does the user receive an email when the the planning phase is complete?

Again, lets split up this story with encapsulated features into the component parts.

As a user,
I want to be informed when my order is accepted,
so that I my order is being worked on.


As a user,
I want to know when the planning phase of my order has been completed,
so that I can prepare for the survey.

By splitting this type of story up, we make the story smaller and more manageable. We also get the ability to give each story a separate priority.

For example, it may be the case that it's important for a customer to know when their order is accepted, but less important for them to know the order has passed planning stage. As such the second story can be delivered later, perhaps in a separate release, instead of having to delay both features if they were within one story.

Benefits

We've mentioned the benefits of splitting above, but here's a quick recap:

  • They help us to understand the users and their usage better.
  • Stories have a better chance of fitting into a single release.
  • Acceptance criteria proves the want, rather than being wants in their own right.
  • A greater breadth of requirements are captured, resulting in less vague statements.
  • They are easier to estimate, the story doesn't include any hidden functionality.
  • The business has a better understanding of the value of the story.

Here's a visual example of point 2:

As ever, the concept of user stories unfortunately isn't black and white, so let me know what you think of the above techniques, and if you have any others to add?