Background
User stories, a type of Product Backlog Item are short, simple descriptions told from the perspective of the person who desires the new capability, usually a user or customer of the system.
User Stories originated in XP (eXtreme Programming) and they tell the team what they are going to work on, who will use what they are building, and what business value they’re creating.
User Stories are a commons practice in Scrum and they are useful because they shift the focus from writing about the item to discussing it. In fact, these discussions are more important than whatever text is written.
The idea is to make Product Backlog Items, including User Stories, to be small and with as little variability in size as possible, while still delivering business value.
We learned from Lean manufacturing that smaller items flow thru the system faster.
Small Product Backlog Items have the following advantages:
Much easier to understand.
Tend to make estimates more accurate.
When we split into small items, we may realize that that may not be valuable to the user.
Allow the team to get small wins on an almost daily basis, leading to greater engagement.
Reduce risk.
Another advantage of decomposing Product Backlog Items into smaller ones is to reduce size variability which causes additional delay, which is heightened because the variability is at the beginning of the process.
How do we do it?
There are many approaches to User Story decomposition. I will provide a few examples of simple ways to make User Stories small.
In the examples that follow, for the sake of simplicity, I will only use User Story “format” for the story before the split.
Remember that you don’t need the “standard” format to write a story. Many Scrum and XP practitioners prefer to just list a simplified Who, What and Why.
Now let’s see examples of story “splitting.”
Vague Terms
User Story:
“As a traveler, I want the weather application to store several days of weather data and display it while offline, so that I can see the forecast at my destination city when I don’t have cell service”
As you can see, there is a lot there.
If you leave that way, it may not even fit on a Sprint, may be over estimated and can easily be misunderstood. Did I mention risk?
We could “split” the same User Story as:
Create a control that displays a timestamp including time zone info, for the last known weather data retrieval.
Add “no service” to the control when you are “in the boonies.”
Store the next day’s weather data.
Store five day’s weather data.
Maintain the forecast data for the last known weather while offline.
In taking this approach to split the User Story, we will get:
Easy to understand.
Easy to estimate.
Faster to get done.
Less risk involved in delivering each item.
Vague terms doesn’t have a “cake recipe” to split so you have to identify split points during refinement by having conversations between the team members and the Product Owner.
Conjunctions
User Story:
“As a return user, I enter the option to save a credit card number and select it for future purposes, so that I don’t have to type in all of the data each time”
Looking for conjunctions is much easier. Conjunctions are words that are connectors: AND, OR, WHEN, IF, for example, and when they are present in a User Story, they are often obvious opportunities to create a vertical slice.
We could split the User Story above:
Save a credit card number to my profile
Offer the option of using a saved credit card number on a purchase
Encrypt the stored data
Acceptance Criteria
User Story:
“As a non-English speaking user, I want the system to read my locale preferences from my profile and display the appropriately localized version, so that I can read it without having to manually choose each time.”
Since we already seen Vague Terms and Conjunctions, you likely already spot splits.
However, besides that, look at the acceptance criteria as an opportunity to split into small items. I only saw a User Story whose acceptance criteria had 28 bullet points!
This story as the following acceptance criteria:
The system will support all locale policies.
The system will use a URL switch to indicate the locale policy.
The user will see the correct language without manually choosing the language.
You can split each one into a User Story. Smaller, faster to develop and test, easier to understand.
Remember, small items flow faster!
Workflow Steps
The final way to split stories is by thinking about how a user will interact with the system. You can break this user story into several workflow steps, each of them could be developed one at a time.
One example. A system that document interaction with a patient in a hospital. The workflow for a doctor is different of a nurse which is different than that of a pharmacist.
Interfaces
You can split User Stories via interfaces. In this context can for example be different devices or types of devices, such as smartphones powered by Android, iOS or Linux.
Data
Another technique for breaking down user stories can be used when the initial stories refer only to a subset of the relevant data.
For example, a website designed to attract tourists to a particular city. If it is a city known for its museums, the first story might include information about the various museums in that region. Then, you can move to restaurants, parks, etc.
Business Rules
One other way to split stories is via business rules. For instance, imagine on your website or app, you can only order a maximum of 10 items.
You could split into a story that lets you add orders to your cart and another that puts limits on how may items you can order.
Which method do I use?
When splitting User Stories is not a matter of one OR the other. It is almost always a matter of one AND the other.
You will find yourself, the team and the Product Owner using all of the above to create small User Stories that flow faster thru the system, are easier to understand and estimate, reduce risk and allow the team to have “daily wins.”
Slicing Product Backlog Items
Before I conclude this document, let’s talk about horizontal and vertical slices.
This applies to software. Hardware and other kinds of products and/or services may not fit both or either approach.
Horizontal Slicing of Backlog Items
Horizontal slicing, also known as break down involves breaking down items by the kind of work, or the layers or components that are involved.
It does not work well because:
Individual items do not result in working, demonstrable, product.
Increases bottlenecks, instead of reducing them.
Horizontal slices can't be prioritized.
Vertical Slicing of Backlog Items
In vertical slicing, Items are broken down into smaller ones (instead of technical tasks).
When Product Backlog Items are broken down vertically, they are broken down in such a way that smaller items still result in working, demonstrable, software.
Functionality will not be split across technical layers or tasks, but across functional layers.
Conclusion
Splitting and slicing (breaking down) Product Backlog Items of any kind are an important way to reduce time to deliver, minimize risk, facilitate development, and create frequent “wins” for Agile teams. However, remember that splitting and slicing User Stories is an art and not science.