Splitting User Stories in Scrum

Why do we need to split user stories?

Writing User Stories is an art. It needs to be clear to the team what is required and at the same time let the team decide the implantation details by innovating.

The key to writing good User Stories are as follows

The User Stories should be small, typically, No more than 40 person hours of effort
Keeping Stories small allows the team to build incrementally and get validations done along the way.
This helps small value to the end user / stakeholder and allows the stakeholders to provide early feedback

Let us study a few ways in which user stories can be split into smaller stories

Ways to split user stories

Split using menu-structure or a big picture

You can look at the features like a menu structure and do a broad level division. You can consider the structure like a backbone in a menu and submenus. For example, let us see one example of a mobile application for a rental app which consists of a backbone of Reservation, Access, Location, Payments and Support. Each of the backbone elements can be subdivided into smaller items. This way of splitting works beautifully to start with. The next few patterns can be applied to each of the elements of the menu structure.

Split using user types

Each of the functionality can be split using user types. For example, let us take an example of login. Then we can write the user stories as

As a end user I should be able to login so that I can book rental cars
As a sales user I should be able to login so that I can upload sales deals
As a marketing user I should be able to login so that I can display marketing banners to the end user
As an administrator I should be able to login so that I can see the support tickets and resolve them

Split using workflows

Each user goes through different workflows through the system and therefore the splitting can be done with each User Story for each different workflow. Let us take the same login functionality as above and write a few workflows

As an end user I should be allowed to login so that I can book rental cars
As an end user I should be able to change password so that I can secure my login
As an end user I should be able to use forget password so that I can recover my password

Split using Business Rules

Each business rule can be a different User Story. For example, let us say that you are developing an insurance system then the various business rules could be

As an insurance seeker when I select that I am diabetic extra premium should be added
As an insurance seeker when I select that I am a heart patient then corresponding wait period should be applied
As an insurance seeker when I select that I do not have any ailment then no extra premiums should be added
As in insurance seeker when my age exceeds 50 and is less than 60 then the premium calculation should be 1.2 times the premium below

Split using Data Modification tasks

Each data modification element can be a different User Story

As an administrator I should be able to add users
As an administrator I should be able to modify user details
As an administrator I should be able to delete user
As an administrator I should be able to reset the password on behalf of user

Split using various types of Data

Each variation in data can be different User Story

As an end user I should be able to save my data in English language
As an end user I should be able to save my data in Hindi language
As an end user I should be able to save my data in French language

Split using major vs minor effort

User stories can be split using minor and major efforts criteria. For example, let us say that we want to build a payment gateway interface. Then we can split them into

Story 1 – Payment gateway interface (major effort)
Story 2 – Master card (minor effort)
Story 3 – Visa card (minor effort)
Story 4 – Amex card (minor effort)

Identify Spikes

Sometimes there are unknowns in a functionality and one does not know how to implement. You can write a few spikes to try out first and then implement. For e.g. you are not sure how to implement a payment gateway then you may try

Spike 1 : Try an interface using vendor 1
Spike 2 : Try an interface using vendor 2
Spike 3 : Try an interface using vendor 3

See what works and then select the vendor and implement the actual user story

As an end user I should be able to make a payment using a credit card

Split using Main flow vs Alternative flow

Sometimes there are main flows vs alternative flows. You can write user stories such as

As a traveler I should be able to book rental car (main flow)
As a traveler I should be able to book car seat for my child (alternate flow for car seat booking)
As a traveler I should be able to book a luxury car and select luxury features (alternate flow for luxury car booking)

Identify performance stories to do them later

Performance features can be added later using a separate user story

As a traveler I should be place an order on stock market using my front end (main story)
As a traveler I should be able to book an order on stock market using my front end AND I should be able to get an order response within 0.1 second (performance story)

Identify scalability stories to do them later

Scalability features can be added later using a separate user story

As a traveler I should be place an order on stock market using my front end and get response within 0.1 second (main story)
As 1 million concurrent travelers I should be able to book an order on stock market using our front end AND still should get response within 0.1 second (scalability story)

Split using types of interfaces

There can be different interfaces to get to the functionality. Each interface can be a separate user story

As a traveler I should be able to login using client software
As a traveler I should be able to login using mobile phone
As a traveler I should be able to login using ATM machine
As a traveler I should be able to login using IVR system

Manual vs automated

User stories can be split using manually doing some functionality vs automated way

As an administrator I should be able to calculate the penalty amount for each customer by clicking a button
As an administrator I should be automatically calculated the penalty amounts by an automated interface

Batch vs Manual

Some functionality can be developed a manual first and then automated

As an administrator I should be able to create users manually
As an administrator I should be able to create users using automated upload of user file

API vs User Interface

It is better to first create an API and then the User Interface

Story 1 – API – As a system I should be able to access the database using API and get required data for booking ticket
Story 2 – Web User Interface – As an Web end user I should be able to get the best prices while booking (using the above API)
Story 3 – Mobile User Interface – As an Mobile end user I should be able to get best prices while booking (using the above API)
Story 4 – ATM Interface – As an ATM end user I should be able to get best prices while booking (using the above API)

Each Error is a separate User Story

Each error can be split up into separate stories

User story on handling Error 401
User story on handling Error 402
User story on handling Error 403

The above article lists some of the ways the user story can be split into smaller stories. While there may be different other ways which we can use to do the same, the simple principle one must keep in mind is that the smaller the better and my recommendation is to keep the size of the split item nothing more than 40 person hours of effort.