10 Techniques to Split User Stories

When it comes to defining user stories, I always give the cake examples to the teams I work it.

The product you are building is like a cake. You tend to make it by layers: first the base, then the moose, then another layer, then the fruits layer, then the cream, and in the end the decorations.

You involve the users all along the building process, as the best practices say. And when you finish making the cake is, and your users taste it, guess what? They don’t like it.

Learning to master the user stories will help you to make complete cake slides for your users to taste from the beginning. So you can deliver end to end experience to your clients. They must eat the slice of cake. It might not have all the decorations, but they can get the full experience.

How you can define user stories to provide end to end value to your clients from the first bite?

For this article, I’ll use an example of the CooLab application. It is an application which aims to connect Cooks with starving people who want to spend time with their families.

Below you’ll find several actors that give life to my examples:

• The Eater is the person who scrolls through the recipes and searches for the recipe to cook next.
• The Cook is the one who wants to share his/her recipes with the entire world
• The Cook helper is the assistant of the cook who helps with the account management.

Here are a few examples to get inspired by:

TECHNIQUE 1: Split the user stories by roles (e.g. buyer, admin, seller). This technique of splitting user stories might be one of the easiest ways to break down your stories into smaller ones. When you are dividing the user stories by roles, you’ll see that most of the effort goes into one user story and the others will have only small adaptations. This is perfectly fine.

First User Story:

As a cook helper, I want to manage messages.

Split User Story:

• As a cook helper, I want to reply to message
• As a cook helper, I want to mark the messages to be answered by the cook

TECHNIQUE 2: Break down the user stories by workflows — I recommend you define first what are the workflows from your product and the actors of each workflow. For example, the cooks can upload images, but the users can visualise them and can have their cooking notebook.

Big Story

As an eater, I want to manage my account

Split Story

• As an eater, I want to upgrade my account
• As an eater, I want to change my profile picture
• As an eater, I want to change my address

TECHNIQUE 3: Divide the user stories by data types. CooLab is an international application, but the currency and the units of measure are as per the user location. That means that the users from the US will see pints and USD and the users in France will see litres and EUR for the same recipes.

Initial Story:

As an eater, I want to load the ingredients of my recipes with the right qualities

Broken Stories:

• As an eater, I want to see the quantities of the ingredients in the metric system
• As an eater, I want to see the amounts of the ingredients in the English system

TECHNIQUE 4: Split the user stories by data entry. In the category of data entry, you can consider any parameter inserted by the user.

Initial User Story:

As an eater, I want to be able to filter the recipes based on time, ingredients, the price for the benefit of finding easier the recipe that meets my criteria

Split:

• As an eater, I want to be able to filter the recipes based on time
• As an eater, I want to be able to filter the recipes based on ingredients so I can use what I have in the fridge
• As an eater, I want to be able to filter the recipes based on price so I can spend as much money as I have

TECHNIQUE 5: Cut the user stories by complexity. A simple way to use this method is by defining the manual way of achieving functionality versus the automated mode.

Initial User Story:

As a user, I want to subscribe automatically to CooLab

Split User Story:

• As a user, I want to subscribe manually to CooLab
• As a user, I want to receive an email with all the information about my subscription to CooLab

TECHNIQUE 6: Break down the user stories by browser/platform 

In the category of the platform, you can include operating systems (Mac, Windows), device types (phone, tablet, desktop), browsers ( Internet Explorer, Chrome, Opera) or anything else that applies to your project. 

Initial User Story:

As a cook, I want to upload the images of my recipe so that my starving fans can have a real picture of how the recipe looks like

Split User Story:

• As a cook, I want to upload the images of my recipe using a laptop
• As a cook, I want to upload the pictures of my recipe from my phone
• As a cook, I want to upload the photos of my recipe using IE
• As a cook, I want to upload the pictures of my recipe using Chrome

TECHNIQUE 7: Split the user stories by business rules (e.g. the card must be issued in the same country as the seller, the investment amount must be more significant than X)

Business rules are criteria or the logic of linking the parameters between themselves. 

Initial User Story

As a user, I can subscribe to the premium version of the application/CooLab

Split User Story:

• As a user, I can subscribe to the premium version of the application/CooLab using only a credit card issues in the same country I am using the application form
• As a user, I can subscribe to the premium version of the application/CooLab only ones for each credit card
• As a user, I can subscribe to the premium version of the application/CooLab only ones for each email address

TECHNIQUE 8: Divide the user stories by CRUD type of operations

CRUD stands for:

• C = create
• R = read
• U = update
• D = delete

They are standard operations the users can do. 

Big user story before using CRUD split

As a cook, I want to manage my recipes for the benefit of sharing them with the entire world

Split User Story

• As a cook, I want to create a recipe
• As a cook, I want to read the recipe that I just created a recipe
• As a cook, I want to update my recipes
• As a cook, I want to delete my recipes

TECHNIQUE 9: by acceptance criteria

As a cook, I want to upload an image to my recipe for the benefit of making my recipes look delicious

Add the acceptance criteria in the following format:

• GIVEN scenario
• WHEN action
• THEN result

Then you’ll realise that you have three acceptance criteria for your user story:

• one for just uploading the image
• one for editing the image after being uploaded
• one for the error message the user must receive in case the picture is massive.

All these three acceptance criteria can be split into three user stories with one acceptance criteria per user story

Broken User Stories:

• As a cook, I want to upload a small image to my recipes

GIVEN I want to upload the picture of my recipe

WHEN I select the picture

THEN it uploads it to the application

• As a cook, I want to edit the image I uploaded to my recipes

GIVEN I uploaded the image of my recipe

WHEN I open it

THEN I edit it

• As a cook, I want to receive an error message when I upload a big picture to my recipe

GIVEN I’m uploading an image bigger than 25mb to my recipe

WHEN I select the picture

THEN I receive an error message

TECHNIQUE 10: Mix them all! The moment you start to mix up the techniques of splitting user stories that I gave you above, you know that you rock it! The success is in combining the methods that work for a particular case: team, product, project, user story.

Try applying the techniques above and let me know how it goes. I’m curious to learn about your experiences.

Do you have troubles in splitting your user stories? Drop me a message; I’ll be glad to help you!