This post begins with an overview of what attributes user stories should have, then covers story splitting patterns.
When writing users stories, strive to make sure that each user story has as many of the INVEST attributes as possible, where INVEST stands for:
Independent — To the maximum extent possible, one story should be independent of another. This is particularly important for stories that are being worked on during the same iteration, since dependencies between stories during the same iteration complicate planning and prioritization. Look for ways to split or modify stories to reduce or eliminate dependencies within an iteration.
Negotiable — A story is negotiable, in that the physical story card (or electronic representation of it) is intended to be an “invitation to a conversation” with the team(s) that are going to build it. The details associated with the story are worked out during this conversation.
Valuable — It is important to word each story so that the business value associated with the story can be readily understood. This is why the Product Owner plays such an important role in helping the team understand the “why” and the “what” of the user story. The technical detail (the “how”) associated with each story is to be found in any descriptive details and/or individual tasks associated with that story, and the team determines the “how” based on their understanding of the “why” and the “what.”
Estimable — (For teams that are using estimation) At the very least, the story needs to be clear enough for the team to be able to do an initial estimate of the story’s relative size. Common issues that can impede the team’s ability to estimate include lack of domain knowledge (which is why the “conversation” around the story is so important) and stories that are excessively large (in which case the story needs to be split into one or more smaller stories).
Small — A story has to be small enough to be completed during an iteration. Depending on team size, iteration length, and other factors, teams typically make stories small enough so that at least half a dozen can be completed during an iteration. In short, larger stories create problems for teams, and thus teams should seek ways to break stories into smaller parts.
Testable — If a story is not testable, it is virtually impossible for the team, not to mention the Product Owner, to know when the story is “done.” A classic anti-pattern is when a story contains imprecise language such as “easy to use” (since there is no straightforward way to test ease of use). Therefore, Acceptance Criteria need to be written in such a way that the testing approach can readily be derived from them.
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:
1. 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.
2. 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.
3. 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.
Evaluate the split stories
Here are some questions you need to ask to determine whether the original story is split as well as it can be, and whether the post-split stories need further work:
1. Are the post-split stories roughly equal in size? Yes/No. If No, consider applying a different pattern to split the original story, or choose a pattern with which to split any post-split story that is/are larger than the others.
2. Do each of the post-split stories have all of the INVEST attributes? Yes/No. If No, consider applying a different pattern to split the original story, or refactor any of the post-split stories that need rework.
3. Do any of the post-split stories reveal especially high-value or low-value work? Yes/No. If Yes, work with the Product Owner to determine whether the work in a post-split story is: a) higher in relative priority than other post-split stories; and b) necessary (sometimes the exercise of splitting stories reveals work that is not really necessary).
The story splitting content is based on patterns observed and compiled by Richard Lawrence on his blog.