Before a user story is ready to be scheduled for implementation in an upcoming iteration, it should be “small enough,” the usual rule of thumb being “a story that can be completed within the iteration”. However, many user stories start out larger than that. “Splitting” consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
1. Prepare the story to be split
Here are several Yes/No questions you need to ask to make sure the story can be and should be split:
- Does the story have all of the INVEST attributes (with the exception of small)? Yes/No. If No, first refactor the story before attempting to split it.
- Based on its current size, is the story too large to be completed during the current iteration? Yes/No. If Yes, it should be split.
- Based on its current size, is the story likely to consume a large amount of the team’s capacity? Yes/No (for instance, if the team typically completes six or more stories per iteration, a story should not consume more than about 1/6 of that team’s capacity). If Yes, it should be split.
2. Apply splitting pattern(s)
When considering how to split a story, keep the following guidelines in mind:
- Choose a pattern that results in one or more post-split stories that can be deprioritized or even eliminated. Suppose that applying one split pattern exposes low-value functionality and another does not; this may be a sign that application of the latter split conceals waste (i.e., low-value work) inside the post-split stories. Apply the split pattern that makes it possible to deprioritize or eliminate work.
- Choose a pattern that results in similarly sized post-split stories. If the post-split stories are similarly sized, it makes prioritization easier.
The split patterns discussed here are:
- Workflow Steps Pattern
- Business Rule Variations Pattern
- Simple/Complex Pattern
- Variations in Data Pattern
- Data Entry Pattern
- Operations Pattern
- Defer Performance Pattern
- Break Out a Spike Pattern
Workflow Steps Pattern
Suppose that a particular story is based on a well-established workflow. Thus this pattern splits the larger story along the lines of individual steps in the workflow, such as:
- As an author, I want to be able to submit my article.
- As an editor, I would like to get notified when an article has been submitted so that I can review it.
- As an editor, I need to approve an article.
- As an editor, I would like to be able to request more information.
Business Rule Variations Pattern
This pattern seeks to separate business rules that are present in a particular story, looking for opportunities to split the story based on differences between/among those business rules. Here are a couple of example business rules:
- Payment currency must be specific to purchase location
- Cash payment denomination amount must not be greater than . . .
- Payment change amount is calculated as . . .
- Receipt bar code is designed using . . .
With the simple/complex pattern, look for opportunities to modify a story that is very general (which often hides complexity). Attempting to define acceptance criteria for each piece helps to facilitate this process. For example, the story …
- As a loan applicant, I want to calculate my mortgage payments, so that I can decide which type of loan is right for me.
Might be made more specific by adding various ways the applicant could accomplish their goal, such as …
- … calculate payments manually
- … calculate payments using an online spreadsheet template
- … calculate payments using an online calculator
Variations in Data Pattern
In this pattern, the focus shifts to data objects. Work with the Product Owner to choose data object options based on user roles and actions. Suppose that there are data objects called Product, Payment, and Receipt. In this instance, the idea would be to focus on specific data types for each object type. So for Product, there might be data types such as Book, DVD, and Gift Card.
You can then work with the Product Owner to identify the data type or types with the highest business value and split the story accordingly.
Data Entry Methods Pattern
Complexity sometimes hides in the user interface. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI later. These, of course, aren’t necessarily independent stories— the second story effectively is the original story if you do it first — but it still can be a useful split.
Thus a story such as
- As a traveler, I can search for flights between two destinations, so that I can decide which flight is best for me.
Could be broken out in different ways such as
- …using simple date input fields.
- …using simple destination input fields
- …using date input fields with validation
- …using destination input fields with validation
- …using a fancy date picker/calendar
- …using a fancy map-based destination picker
Defer Performance Pattern
In this pattern, the idea is to look for opportunities to defer work that is making an existing story inordinately large. Trying to achieve a particular performance target via a single story tends to result in larger stories. It is often best to look at system performance as a global constraint that needs to be addressed more broadly.
Here are some additional examples of “non-functional” requirements that are often best considered separately:
With this pattern, try focusing along the lines of operations and procedures. Some teams might look at this in terms of a CRUD (create-read-update-delete) scenario, such as this:
- As a shop keeper I want to manage the products being sold in my online store so that I can sell what people want to buy.
If the above story is still too big, it could be further split based on CRUD operations like this:
- As a shop keeper I want to add and remove products from my online store so that I can sell what people want to buy.
- As a shop keeper I want to edit product details in my online store so that I can avoid recreating a product to fix a typo … (and so on)
Another general rule of thumb is to watch for generic verbs such as “manage,” for example, “as a new student, I want to manage my account.” The word “manage” tends to conceal more specific actions such as “cancel an account,” edit an account,” and so on.
Break Out a Spike Pattern
A story may be large not because it’s complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. Then, you can do the implementation at such a time when you’re in a better position to break it into smaller parts.
Consider the following story:
- As a purchaser, I can pay by credit card.
Such a story could first be investigated via spike, then subsequent pieces could be implemented, such as:
- Spike: Choose a credit card processing approach
- As a first-time purchaser, I can enter my credit card info
- As a returning purchaser, I can use the credit card info stored in my profile
- As a returning purchaser, I can modify the credit card info stored in my profile
- … etc
In the “choose a credit card processing approach” spike, the acceptance criteria would typically consist of the questions that need to be answered. Do just enough investigation to answer the questions and stop; it’s easy to get carried away doing research.
The spike split is last because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.« Back to Glossary Index