Splitting User Stories - What it is and techniques used

What is a user story?

Firstly, let's understand what stories are in agile. It is a short description that talks about the desired function from the perspective of the user. Agile teams size these in such a way that they can be completed in one iteration. These are the basic artifacts that eventually define the system behavior. Both business as well as tech stakeholders can understand the story's intent with ease.

They are of two types: User stories and Enabler stories. The former delivers the functionality to the final user. The latter on the other hand brings more visibility into the building process. In this blog, we will be dealing with user stories, and splitting user stories.

To understand the difference between the two types of stories, let's take this example:

User story (end user): As a commuter, I want to identify the nearest cab I can book so that I can travel to my destination faster.

Enabler story: Use the device GPS and sync with nearby registered device GPS.

In agile, user stories are the most basic means of telling what is the needed functionality. They focus on the end user and are very customer-centric in nature. The subject of interest in a user story isn't the system, but rather the user. User stories also define the business value of the requirement at hand.

So, roughly, a user story would be written combining the following:

User Story = User role + Activity + Business Value.

In the above example, the user role is that of the commuter.

Activity is identifying the nearest cab.

The business value would then be the need to travel faster to the destination.

Through this method of writing user stories, the dev teams understand these things:

• Who would be using the product/ who they are building for
• What the user is doing with the feature
• Why are they building the product?

Now that we know what user stories are, let's move on to understanding splitting user stories.

What does 'Splitting user stories' mean?

When a user story is ready so that it can be scheduled for implementation, it should be 'small enough'. What this means is that the story should be such that the developers can complete it in one iteration. This is a general rule of thumb around user stories.

The agileINVEST acronym states the characteristics of a good user story and can be cited here. A quick refresher, this is what the acronym stands for:

I - Independent

N - Negotiable

V - Valuable

E - Estimable

S - Small

T - Testable

As is clear, the S-Small suggests that user stories are to be small in size. These allow faster implementation, and are also more reliable. This is because being small in size, they flow through the system with a less amount of risk and variability.

However, it so happens that most user stories are complex in nature. They cannot be completed in one iteration.

This is where user story splitting comes into play. As you might have already figured, splitting user stories means to split a bigger, more complex user story into a smaller one to complete it in one go. This process is also known as story splitting. Since a user story has three parts, the role + activity + business value, it's a must to keep these on splitting. So, story splitting is done such that each story has a measurable business value by itself.

But, how is this done? Well, there is no one way for splitting user stories. The ways of doing this depend on the business domain and hence various authors have their own ideas on how to do it. In the coming sections we will touch upon some of the ways of splitting user stories.

Agile Techniques for Splitting User Stories

These are some of the common ways of splitting user stories:

1. Story splitting by capabilities offered

In this, you have to look at the capabilities being offered by each user story. For example, if a main user story needs you to search as well as sort, you can split these into two. You can also then further split these if you have multiple ways of sorting and searching in each.

2. Based on the devices the app is to be used on

You can't expect all the users using your software to use it on the exact same type of system. For this, you have to make accommodations for devices, settings, and other things. So, you can split user stories based on these differences and work on one at a time.

3. Splitting based on user roles

Note that the same software would be used differently by different users. For example, consider a recruitment portal. The users would be using it in a different way than the HR managers. Same thing for educational software, teachers and students wouldn't be using it in the same way. Thus, you can define the different roles of people who would use the system. Through this, you can also split the features and work on them accordingly. In this way, it's easier to address the varied needs of each user.

4. Splitting user stories based on user personas

Again, after user roles, user personas also could differ. This would depend on a number of things. For example, if a person has a lot of knowledge about the system, they'd want shortcuts so that they can work faster. A newer user would need a lot of guidance on the system and you'd probably have to integrate a lot of tips or guides. Someone with a physical handicap would need to interact with the feature in a different way.

Based on such differences in personas, you can split your user stories so that you are focusing on only one at a time.

5. Split user stories by workflows

One main feature can be divided into a number of smaller ones. Take, for instance, posting a photo on an app like Instagram. You'd first choose the picture from your gallery, or click one. Then, you might want to make some edits to the picture. Next, tagging people and adding a location and caption would come into play. After all these things only would you post the picture.

Of course, the example we've taken is bound to be more complex than this, but the basic idea is to split based on the flow. So each of these tasks can be worked on as a separate user story.

6. Split based on data types

Here, we shall consider local ways of entering data all over the world. Suppose you are creating an app to track the amount of steps you take a day and the distance covered. In the USA, you'd have to show this data in miles. But, in India, you'd have to show the same data in kilometres. So, when making an app, you'd come across different ways of entering data. You can split user stories based on the data types accordingly.

7. Splitting user stories by the CRUD operations.

As you might know, CRUD stands for Create, Read, Update and Delete. You can split your user stories into smaller ones based on this. This way, a smaller user story would involve only dealing with the Creation of something. Another might deal only with the way users Read certain data.

The SPIDR method for splitting user stories

The SPIDR method is a relatively new way of splitting user stories. It stands for:

S - Spikes

P - Paths

I - Interface

D - Data

R - Rules

Let's understand how it works.

1. Spikes
   Spike is a method to make the development team more aware of the things they are doing. Technical unknowns tend to make a story large, so the team needs to learn before making user stories. Only after understanding the components in detail do they work on writing and splitting the user stories.

2. Paths
   There could be multiple ways of carrying out a function. Say to pay online, you could use credit or debit card or some other way. User stories are then made to tackle each of these.

3. Interfaces
   This is similar to the point about devices mentioned earlier. You can split user stories based on the devices and interfaces users will be interacting through.

4. Data
   The data would be entered in different ways. Take for instance filling a form. Here, you could work on one story for collecting and storing basic user data such as name and location. Another story could then collect the picture.

5. Rules
   User stories would have some restrictions to make it function well. So, you can split and add just one rule at a time in each user story. For example, the first user story would be open and have no restrictions and collect any sort of data. The next ones can add various restrictions on this data.

Originally published here.

P.S. If you liked the above article, also check out the following:

1. Three Daily Scrum Questions
2. Category Development Index
3. Minimum Marketable Feature
4. Authorized Shares
5. Team Facilitator
6. High low pricing
7. Everyday low pricing