Photo by Joshua Brown on Unsplash

Back to Basics: Writing and Splitting User Stories

Bill Wake’s user story attributes

This post begins with an overview of a set of attributes that well-formed user stories tend to have, then covers story splitting patterns.

Story Attributes

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
• Negotiable
• Valuable
• Estimable
• Small
• Testable

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 (Sprint), 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.

Story Splitting

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.

Split Patterns

The split patterns discussed here are:

• Workflow Steps
• Operations
• Business Rules Variation
• Variations in Data
• Data Entry Methods
• Major Effort
• Simple > Complex
• Defer Performance
• Break Out a Spike
• Find the Complexity and Reduce the Variations (meta-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 submit my article.
• As an editor, I want to get notified when an article has been submitted.
• As an author, I want to request clarification from the editor
• As an editor, I want to improve an article

Operations Pattern

With this pattern, try focusing along the lines of abstractions or CRUD (Create-Read-Update-Delete) operations. Suppose we start with this story:

• 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

… and we then split it something like this:

• As a shop keeper, I want to add products to my online store, so that I can sell what people want to buy.
• As a shop keeper, I want to view the products in my online store, so that I can check for accuracy.
• As a shop keeper, I want to update a product description, so that it accurately reflects product cost and description
• As a shop keeper, I want to remove products from my online store, so that I don’t distract shoppers with items few people buy … (and so on)

Another general rule of thumb is to watch for generic verbs such as “manage” or “administer,” 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.

Business Rules Variation 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 some sample variations based on a generic E-Commerce context:

• Payment currency must be specific to purchase location
• Cash payment amount must not be greater than . . .
• Refund amount is calculated based on . . .
• Receipt bar code is based on . . .

Variations in Data Pattern

Identify data objects that may have variations based on roles and/or user actions, and consider splitting based on those variations.

Example:

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, based on those data types. Continuing with the example above:

• A first-year student chooses a book
• A music student chooses a DVD
• A parent chooses a gift card

Data Entry Methods Pattern

As User Interfaces evolve, various options for user data tend to surface. This technique can also be helpful when considering what to include/what to leave out in a Minimum Viable Product (MVP).

Example:

As a business traveler, I want to search for flights, so that I can evaluate scheduling options. Possible variations in the story, based on data entry methods:

… entering a date range manually.

… using a calendar UI (popup).

… completing a step in a workflow (wizard)

Major Effort Pattern

There are many situations where a larger chunk of work needs to be done first, and then subsequent stories leverage the work that was done on the first story.

Consider a case where credit card payments need to be processed:

• As a returning student, I want to buy the books I need for my courses with a credit card, so that I have a separate record of my transaction from my bank.

The variations might look like this:

• … paying with a Visa card (where much of the initial work would be done on this story)
• … paying with a Master Card
• … paying with a Discovery card
• … paying with an American Express card

Simple > Complex Pattern

Look for stories that hide complexity. One of the most common ways complexity might be manifested is via Acceptance Criteria, which could offer obvious clues for potential splitting. Consider this user story:

• As a loan applicant, I want to calculate my mortgage payments, so that I can determine what type of loan might be best for me.

This story could potentially be split in many ways, moving from simple to increasingly complex:

• … calculate payments manually
• … calculate payments using an online spreadsheet template
• … calculate payments using an online calculator calculator

Defer Performance Pattern

Look for opportunities to defer some work until later, by first proving out a basic concept, and then iteratively making it more robust. Consider the following example:

• As a library patron, I want to search the online library catalog, so that I can decide whether I want to make a trip to this library.

Since we’re talking about a form of search, we might gradually improve search performance over time, something like:

•… returning search results in 3 seconds

•… returning search results in 2 seconds

Note: Be careful with this pattern. It might make sense to use this when a team is just starting out, and gradually make the Definition of Done more stringent over time, as supporting infrastructure allows.

Break Out a Spike Pattern

Often Stories are not necessarily overly complex, but just have many unknowns, like making a decision on which software library to use.Suppose for example that you didn’t understand how Paypal worked, and you had this story in the backlog:

• As a seller, I want to collect payment with Paypal, so that I can grow my customer base by accepting one of the most popular payment methods.

Spike: Answer one or more of these questions:

• How does Paypay work?
• How do I know I have a successful payment?
• How do I know when a payment is unsuccessful and what options can I present to the buyer?

Or, suppose we’re talking about processing credit card payments, and we want to 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

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.

Note: The placement of the spike after other patterns is meant to imply that we should consider it a last resort. We probably know enough to build something. After we do that, and we’ll know more. So, we should make every effort to use one of the previous patterns before resorting to the spike pattern.

Find the Complexity & Reduce the Variations

This is a “meta-pattern,” meaning that the basic thought process is present in many of the preceding splitting patterns. Just for practice, we could start by applying this pattern first on some stories, then choose some of the other patterns to experiment with.

Steps:

1.Find the core complexity. What’s most likely to surprise us? It’s often where human preferences or behavior can determine sequencing or outcomes, or it might be an area with a new integration or external dependency.

2.Identify the variations. What are there many of? Consider things like business rules, user types, interfaces, etc.

3.Reduce all the variations to one. Find a complete slice. It could be a single scenario, or it might be a range of scenarios through a single business rule variation.

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).

References

The story splitting content is based on patterns compiled by Richard Lawrence and Peter Green on the Humanizing Work website.