How to get started working on small things — Breaking down user stories

Learning how to split user stories can be a game-changer. Break down user stories into smaller tasks to tackle big projects more efficiently. Start today and increase your focus and productivity.

Picture this: you have assembled your product layer by layer, like a carefully crafted cake. First comes the base, then the mousse, followed by another layer, then the fruit layer, then the cream, and finally, the decorations. But after all that effort, when your users take a bite, guess what? They don’t like it.

If we want to go faster, it’s essential to capture, write, and split user stories effectively. We’ve previously discussed what a user story is:

Here, we are going to see that the goal of a user story is to describe and create increments of user value that can be implemented by a development team in a short amount of time, typically on the order of hours or, at most, a few days (1–2)

The beauty of creating individual small stories is that they can stand alone and still make a more significant impact when compiled into a larger feature. Remember to gather feedback and make necessary adjustments along the way, always.

Creating good user stories will have a tremendous impact on predictability within our teams, which will be discussed in a future post.

Does this deliver value to the user?

Many teams struggle to split large user stories and features into good, small stories. Fortunately, story splitting is a skill that can be learned in a relatively short time.

Years ago, INVEST was coined by Bill Wake, Extreme Programming pioneer, to describe the six essential characteristics of a good user story.

Independent: Every single story has the potential to be released.
Negotiable: The development team can negotiate the story’s scope and contents with the product owner, encouraging all team members to contribute good ideas.
Valuable: Each story has its own value for the user.
Estimable: Each story is concrete enough that the delivery team can give an approximate estimate as to how big the story is if needed.
Small: The team can receive quick feedback by completing the story in a short amount of time.
Testable: The story can be tested. In the agile world, “tested” means that a set of automated tests, including unit, integration, and acceptance tests, is delivered with the production code.

Story-splitting techniques

There are many techniques for splitting stories. Here are some of the more useful ones:

Split by capabilities offered

One of the most apparent methods to divide a substantial feature is to examine the various functionalities it offers and separate each one into individual stories. For instance, the abilities to search, filter, and sort can be split into separate stories. Additionally, each method of searching or sorting can be further separated into its own story.

Split user stories by workflows

First, define the workflows and actors for your product. For instance, cooks upload images, while users view them and have cooking notebooks.

Big User Story
As a Rider, I want to manage my account
Split User Story
As a Rider, I want to upgrade my account
As a Rider, I want to change my profile picture
As a Rider, I want to change my address

Split by User Roles or User Personas

System administrators and teachers have unique roles and needs when interacting with software. Splitting features and stories based on these roles results in better user experiences.

Users interact with software differently, even if they have the same role. Power users prefer keyboard shortcuts while casual users prefer intuitive assistance. Handicapped users may require alternative methods of interaction to complete the same tasks as other users.

Split by target device

When designing your system, it’s important to consider that users may not interact with it using a standard computer. This means you need to take into account various smartphones and IoT devices. To provide a more natural experience for your users, it’s best to split stories by device. You can group them by platform, which includes operating systems (such as Mac and Windows), device types (like phones, tablets, and desktops), browsers (including Internet Explorer, Chrome, and Opera), or anything else that applies to your project.

Big User Story:
As a cook, I want to upload 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 images of my recipe using a laptop
As a cook, I want to upload pictures of my recipe from my phone
As a cook, I want to upload photos of my recipe using IE
As a cook, I want to upload pictures of my recipe using Chrome

Split user stories by data types.

Your product is designed to display currency and units of measure based on the user’s location. This means that users in the US will see USD and pints while users in France will see EUR and litres for the same recipes. This makes the application truly international while still catering to individual user preferences.

Big User Story:
As an eater, I want to load the ingredients of my recipes with the right qualities
Split User 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

Split user stories in Agile by Cutting the user stories by complexity

A clear way to apply this approach is to contrast manual and automated functionality.

Big User Story:
As a user, I want to subscribe automatically
Split User Story:
As a user, I want to subscribe manually
As a user, I want to receive an email with all the information about my subscription

Split 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:
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

Split using zero/one/many method

After utilizing various of these previous techniques to distinguish valuable stories and dividing them into smaller pieces, you may still have stories that are too extensive. In such cases, implementing the “zero/one/many” rule can be beneficial for the team to stimulate creativity and keep breaking down stories into manageable vertical slices.

With the zero/one/many approach, you ask these three questions:

What happens if we are dealing with nothing?
What happens if we are dealing with one thing?
What happens if we are dealing with many things?

Big user story:
As a teenager, I want to borrow books so that I can enjoy reading that would otherwise be unavailable to me.
Split User Story:
As a user, I want to know that the library is empty so that I don’t waste my time trying to borrow books that are not available.
As a user, I want to be able to read a book in the digital library so that I can enjoy it.
As a user, I want to borrow from a bounty of books so that I can enjoy reading that would otherwise be unavailable to me.

Other ways to apply Zero/One/Many: