Splitting Features / User Stories using 10 splitting patterns

User story splitting is a hot topic in software engineering and product development. Richard Lawrence defined 3 steps and 10 patterns to split user stories. Many posts are shared on LinkedIn about user story splitting, and many trainers/coaches talk about it but with little or no examples. The purpose of this article is to explain the splitting patterns with examples. Just so you know, I have no intention of writing complete user stories with acceptance criteria and that is a separate topic on its own.

Richard Lawrence highlights that the only splitting 'technique' available is to make sure that a story is small enough to fit into a sprint or an iteration. So if the functionality defined in your user story can be designed, coded, unit tested, functionality tested, defects fixed, and even integrated (as applicable) then the user story has been split successfully.

3 steps to split user stories:

Step 1 - Start with a user story (It may be massive, it may be big. But just write a story) and check the story against the INVEST (Again, this is a different topic on its own) criteria to see whether the story satisfies all other criteria except SMALL.

Step 2 - Apply the splitting patterns

Step 3 - Check the split user stories to see whether they satisfy INVEST.

Repeat the above 3 steps as long as you can split your user stories!

10 Splitting Patterns to split user stories:

1. Workflow Steps
2. Business Rules Variations
3. Major Effort
4. Simple / Complex
5. Variations in Data
6. Data Entry Methods
7. Defer System Qualities
8. Operations (Example CRUD)
9. Use Case Scenarios
10. Break out a Spike

Now starts my examples:

Let's say we start with the below user story. Note that I will not write a complete story or follow the 'user voice' format as we go along!

'As an administrator, I must be able to manage customers so that I can ..... "

Applying the CRUD operations pattern we may end up with splits as below.

As an administrator, I must be able to create a new customer so that I can ..

As an administrator, I must be able to edit a customer so that I can ..

An an administrator, I must be able to delete a customer so that I can ..

As an administrator, I must be able to view customer information so that I can ..

When functionality includes normal flow, happy paths, and exception flows then we can use the use case scenarios splitting pattern. Now let's split the create new customer story further considering use case scenarios splitting pattern

As an administrator, I must be able to create one new customer at a time ..

As an administrator, I must be able to create multiple new customers at a time ..

As an administrator, I must be able to cancel customer creation ...

Let's take the create one by one user story and investigate further. I will first apply the workflow steps pattern to split further. Let's say that adding a customer record includes multiple steps such as adding basic details, adding contact details, adding payment details, adding past purchase details, etc. So the new splits are,

As an administrator, I must be able to add basic details about a customer so that I can ..

As an administrator, I must be able to add contact details about a customer so that I can ..

As an administrator, I must be able to add payment details about a customer so that I can ..

....

The business rules splitting pattern focuses on variations in functionality based on variations in business rules. Let's consider business rules now. Let's say a customer record gets automatically approved if the credit score is over a certain amount. So, applying business rules variations splitting pattern ..

As an administrator, I must be able to automatically approve a customer record if the credit score is over the eligible amount so that ..

As an administrator, I must be able to handle a customer record if the credit score is below the eligible amount so that ..

Let's consider the View customer functionality now. I will now use the simple/complex splitting pattern to split further. This pattern encourages teams to get simple functionality done first, and then add more complexities to it later.

As an administrator, I must be able to view all customer records so that I can .. (Here it is a simple 'select all' functionality)

Then we can add more complexities to the View as below.

As an administrator, I must be able to view only the top 10 customers so that I can .. (top 10 records on screen)

As an administrator, I must be able to traverse to view more customer records .. (pagination)

As an administrator, I must be able to search for customers ..

And so on .. for more complex implementations

There are instances where the majority of a user story is done when a lot of effort is put in. The rest of the functionality becomes less cumbersome when the bigger portion is done. Here's an example using the major effort/minor effort splitting pattern.

Let's say we need to enable credit card payment methods for customers. Let's hypothetically assume that enabling VISA card payment is hard and takes a lot of time. But once it's done let's say Amex, Mastercard, and American Express are easy to enable. So applying the splitting pattern we may end up with ..

As an administrator, I must be able to enable VISA card so that .. (major effort)

As an administrator, I must be able to enable Amex, so that .. (minor efforts)

...

We often get situations where functionality changes when a certain value is selected (may be from a drop-down, radio buttons, or checkboxes, etc.) New fields/screens often get displayed and whole new functionality gets enabled when such a value(s) is selected isn't it? this is a good situation to split your stories based on variations in data.

As an administrator, I must be able to provide ailment-related information about the customer when the customer is a diabetic so that .. (completely new set of fields displayed)

As an administrator, I must be able to provide past-ailment information about the customer when the customer is a heart patient so that .. (new set of fields)

There are instances where the data may be captured in different ways. A very simple example using the data entry methods splitting pattern is as below.

As an administrator, I must be able to capture date of birth information on screen so that .. (may be a text field, date-time field)

As an administrator, I must be able to capture date of birth information from a file so that .. (may be a text file or a CSV file).

There are many an instance where the functionality, technology is not clear. There are also instances where the developers need to spin up new servers or expand the architecture to support new functionality. These are situations where we need to implement enablers. To capture such situations we can use the splitting pattern breaking out spikes.

For example, let's say we are implementing an administrator dashboard to monitor customer records. A dashlet must be developed so that customer statistics need to be displayed as a histogram. We may capture this as an exploration story as below.

As a developer, I must be able to explore how to generate a histogram using XYZ framework so that ..

As a developer, I must be able to explore how to load customer data to the histogram ..

The differing system qualities splitting pattern is all about focusing on the NFRs or the 'ilities'. Considering aspects such as security, maintainability, performance, scalability, usability, etc. we may end up with additional user stories.

For example, in order to improve the maintainability of the solution we may want to archive deleted records that are more than 1 month old.

As an administrator, I must be able to archive deleted customer records so that ..

We may sometimes want to roll back to a previously stable state of functionality.

As an administrator, I must be able to roll back deleted customer records so that ..

As you can see you may actually end up with many user stories once you apply splitting patterns. This might be overwhelming and it is certainly not a one-time activity. Teams must continuously apply splitting patterns multiple times until an optimal split is obtained.

I hope this article helps those who are struggling to split user stories in an agile environment.