10 strategies to split large user storiesTweeter
Posted by jc-Qualitystreet on 2011/04/19
A user story is a requirement of the system to be developed, a brief description of a feature as viewed by the user (Role → Goal), very popular on Agile projects.
« As a customer, I want to book a train ticket to go to Paris »
User Stories are usually associated to the 3C rule, quality criteria (INVEST) and the « User Voice » format…
As a <User Role>
I can <Goal>
So That <Business Value>
Each user story must be estimated (by the team) and prioritized, but also SMALL ENOUGH to be delivered in a sprint (usually smallest teams take at least 3 stories per sprint). This is a necessity if you want to observe real benefits in terms of value delivery, visibility, flexibility, feedback and continuous improvement.
During my agile coaching activities, I am regularly asked to help the team and Product Owner to split user stories into smaller ones.
Here are the 10 strategies I use to effectively split large user stories:
1 Steps of a workflow
The user performs a task according to a well-established workflow. The large user story is split according to these steps in order to be developed incrementally. Each step has its own user story.
By splitting a user story by scenario, you get a User Story for the main success scenario and other user stories for any errors or alternative paths:
when x happens, then…
3 Sequence in a scenario
The case is more precise, you divide the story according to a specific sequence in a scenario.
Splitting a user story by operations is often the most obvious way to decompose. A CRUD (Create, Retrieve, Update, Delete) feature is a good example. Separate the CRUD or group two operations in a user story may be appropriate … to create an account, to view it, edit it and delete it.
5 Size or type of data
Pretty obvious too. You divide large user stories according to the type of object (e.g. various account types, messages in English, French, Spanish…)
6 Type of input, output or configuration
Variations in terms of material or not, on configurations but also in terms of input means or User Interface can lead to new and smaller user stories.
7 Persona or role
This time, you choose to break down the user stories based on the role or the persona who will use the product. This is a very good option easy if you use the user voice format or the Persona approach. The story mapping activity is a good way to visualize it.
8 Level of knowledge
The level of knowledge acquired on a feature is a good criterion of decomposition… You can get a specific story for what is known, another one for the unknown (leading to a spike and exploration activity)
9 Level of complexity
For example a user story can describe a feature in the simplest way of implementation, others will follow by a greater level of complexity or detail.
10 Level of quality expected
Performance, Security, Usability … these non-functional requirements are usually described in the elements of conversation, of a specific user story. There are conditions of satisfaction, but they can also help distinguish between these user stories (eg display it in less than 60 seconds, less than 30 sec; data in real time or not …)
Illustrations will be added progressively. If you want to participate, please submit your comments with your example and strategy number…Tweeter
Vin D'Amico said,
Excellent suggestions! Creating small stories is a huge problem for many agile developers. There is a tendency to generalize the stories but you can’t test generalities.
Stories need to be specific and measurable. Your ideas represent excellent approaches to cutting stories down to size and making them actionable.
Pierre FAUVEL said,
Hi, Jean Claude,
I would add « level of priority ».
Sometimes a user story can be split in two, one being of very high business value, one of less value. The fact that one is not very sure of the priority of a user story is a hint that it should be split.
Agile Scout said,
Great tips on this! Thanks a bunch for posting this up!