Agile methods have revolutionized the way software and products are developed. New functionality that can potentially be delivered is built in short cycles. This allows us to get feedback from users quickly and make adjustments if necessary.
One of the central practices in agility is the splitting of user stories, also known as user story splitting.
In this article, I will discuss which problems we can solve with user story splitting. From this, you will see why user story splitting makes sense. And then we'll take a look at exactly how user story splitting works and where it can be used.
Overview
- Definition of Done not fulfilled - what now?
- Why unfinished user stories are a problem
- What is the 90% syndrome
- Why user story splitting?
- How does user story splitting work?
- Is splitting only possible for user stories?
Definition of Done not fulfilled - what now?
The following scenario can happen even to the best Scrum teams. At the end of a sprint, a story cannot be completed in the sense of the Definition of Done. The question then arises as to what to do with the half-finished solution.
The short answer to this is simple. The story is not considered implemented (there is no such thing as "half-finished" in Scrum). It therefore does not become part of a release package and goes back into the backlog. There it is treated like any other story.
Product owners often complain that this usually happens with what they consider to be the most valuable user stories. The most valuable are usually also more complex user stories.
According to Scrum, the estimated story points of an unfinished user story are not included in the velocity.
Only completed stories are presented in the sprint review. This Scrum rule makes perfect sense. It prevents teams from giving themselves and stakeholders a false picture of their progress.
Why unfinished user stories are a problem
Of course, it can happen that a user story is not completed in the sprint. However, if this happens regularly, it leads to the following problems
- the velocity is inconsistent and becomes unpredictable
- Sprint planning thus becomes a challenge
- we can show and experience less progress because work is not completed
- Sprint reviews become a disappointment because the work is not done
What is 90% syndrome?
Perhaps you have already experienced the 90% syndrome. The developers start working on a story. After a week, you receive the information that the 90% story is finished.
In the course of the second week, new findings and unforeseen additional work arise. The developers continue to work diligently. At the end of the week, they are finished with the story at 90%.
The same is repeated in the third week...
In an agile environment, we don't actually want to know an exact percentage status, as this is usually a misjudgement. We only ask a very simple question: is the story finished or not?
Why user story splitting?
In Scrum, we want to continuously create added value for the user. We divide our work into small steps. This allows us to receive feedback from the user at each completed step, learn from it and make adjustments if necessary.
So before we drag a potentially too large user story into the sprint, we prefer to split it into smaller pieces. This makes it more manageable. And we need less "luck" to complete it in a sprint.
User story splitting is particularly useful for complex user stories. It reduces the risk of user stories not being completed in a sprint. By splitting into smaller, more manageable chunks, teams can focus on specific tasks and make progress more efficiently.
How does user story splitting work?
Broadly speaking, there are various methods for splitting user stories, including
- Functional division
We split the user stories based on the functionality they provide.
For example, we can break down a user story for creating a new user account as follows:- User registration
- Registration
- Password recovery
- Vertical division
We divide the user stories by feature or component.
Example of a user story for implementing a search function:- Design of the search bar
- Display of search results
- Implementation of the search algorithm
- Horizontal division
This technique involves splitting user stories according to user role or persona.
This means that each role has its own user story.- User story for normal users
- User story for admin users
- User story for customer
User story splitting helps teams to work better together. Complex user stories are split into smaller stories. These can be worked on independently of each other.
This allows team members to work on specific tasks and make progress more efficiently. User story splitting helps teams
- improve their development process and
- Deliver better software in less time
Is splitting only possible for user stories?
The user story splitting strategies also work for larger work packages. Whether epics, features or in a classic environment only plays a subordinate role.
In our booklet "User Story Hacks", we take a closer look at the individual splitting strategies: Spikes, Paths, Interfaces, Data, Business Rules, Roles, Defer Quality, CRUD Operations. You will also receive many other valuable tips and tricks for simply better user stories.
Click here to receive your free copy today.
Due to many interested queries, I have decided to write a separate article for each splitting strategy. There, the respective strategy is explained in detail and we go through it together using an example.
Deutsch (Schweiz) 
English