back to notes

Splitting User Stories

Splitting User Stories
Created by Hokans, Becca, last modified on May 01, 2019

How Small?

How small should stories be? The recommendation depends on your team’s velocity. Before your next planning meeting calculate what estimate should trigger splitting a story. For most teams, it seems to be 8 or 13 points. When you’re in a planning meeting and you hit your trigger estimate, try a few of the patterns until you find a good split.

Which Pattern to Use

You’ll often find that you can split a story using several of the patterns. Which split should you choose? Use these two rules of thumb:
Choose the split that lets you deprioritize or throw away a story. The 80/20 principle says that most of the value of a user story comes from a small share of the functionality. When one split reveals low-value functionality and another doesn’t, it suggests that the latter split hides waste inside each of the small stories. Go with the split that lets you throw away the low-value stuff.
Choose the split that gets you more equally sized small stories. The split that turns an 8 point story into four 2 point stories is more useful than the one that produces a 5 and a 3. It gives the Product Owner more freedom to prioritize parts of the functionality separately.

Pattern #1: Workflow Steps

Here’s a story from a content management system one of my clients was creating:

As a content manager, I can publish a news story to the corporate website.

Didn’t sound too big—until we dug into the workflow to get a story published. It turned out that just to get a few sentence news story on the corporate website required both editorial and legal approval and final review on a staging site. There’s no way 6-10 stories like this would fit in an iteration.

In a workflow like this, the biggest value often comes from the beginning and end. The middle steps add incremental value, but don’t stand alone. So it can work well to build the simple end-to-end case first and then add the middle steps and special cases.

The new stories included:
…I can publish a news story directly to the corporate website.
…I can publish a news story with editor review.
…I can publish a news story with legal review.
…I can view a news story on a staging site.
…I can publish a news story from the staging site to production.

Sometimes, though, the whole workflow matters, so you can’t just start with the beginning and end. In those situations, look for a thin slice through the whole workflow. Maybe it supports the most common case. Maybe you hard-code or otherwise simplify the best understood parts of the workflow to you can explore the more complex parts.

Either way, the most obvious split—one step at a time from beginning to end—is the wrong way to go.

Pattern #2: Business Rule Variations

This story has a few equally complex stories hidden within it that accomplish the same thing using different business rules:
As a user, I can search for flights with flexible dates.

Digging into “flexible dates” reveals several different business rules, each of which can be a good story on its own:

…as “n days between x and y.”
…as “a weekend in December.”
…as “± n days of x and y.”

Pattern #3: Major Effort

Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one. For example, this credit card processing story,

As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express.

could be split into four stories, one for each card type. But the credit card processing infrastructure will be built to the support the first story; adding more card types will be relatively trivial. We could estimate the first story larger than the other three, but then we have to remember to change our estimates if the Product Owner later changes priorities. Instead, we should defer the decision about which card type gets implemented first like this:

…I can pay with one credit card type (of VISA, MC, DC, AMEX).
…I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).

The two new stories still aren’t independent, but the dependency is much clearer than it would be with a story for each card type.

Pattern #4: Simple/Complex

When you’re in a planning meeting discussing a story, and the story seems to be getting larger and larger (“what about x?”; “have you considered y?”), stop and ask, “What’s the simplest version of this?” Capture that simple version as its own story. You’ll probably have to define some acceptance criteria on the spot to keep it simple. Then, break out all the variations and complexities into their own stories. So, for example, this story,

As a user, I can search for flights between two destinations.

stays simple by splitting off variations like,

…specifying a max number of stops.
…including nearby airports.
…using flexible dates.
…etc.

Pattern #5: Variations in Data

Complexity in a story can come from handling variations in data. For example, a system I’m currently working on needs to model geographic areas served by transportation providers. We could have burned our whole project budget just handing geography; it’s potentially that complex. When I talked through the story,

As a user, I can search for transportation providers by trip origin and destination.

with our Product Owner, I discovered that, while we didn’t need full-fledged GIS, modeling geography would still be quite complex. We stopped and asked, “What’s the ‘good enough’ way to model geography so we can build other high-value features now?” We settled on,

As a user, I can search for transportation providers by trip origin and destination as counties.

This worked for a while, until we collected more data and found that some providers only served certain cities or even neighborhoods. So a new story came up:

As a user, I can search for transportation providers by trip origin and destination as counties, cities, towns, or neighborhoods.

Looking over the new provider data, we also discovered that some providers will support trips originating in a single city but ending in any number of surrounding cities. This led to the story:

Providers can serve different geographic areas for trip origin and destination.

All three of these stories are split from the original geography story. The difference here is that we added stories just-in-time after building the simplest version. But sometimes you know the data variations up-front. The classic example is localization:

As a content manager, I can create news stories.
…in English.
…in Japanese.
…in Arabic.
…etc.

Pattern #6: Data Entry Methods

Complexity sometimes is in the user interface rather than in the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI. These, of course, aren’t independent—the second story effectively is the original story if you do it first—but it still can be a useful split.

As a user, I can search for flights between two destinations.
…using simple date input.
…with a fancy calendar UI.

Pattern #7: Defer Performance

Sometimes, a large part of the effort is in making a feature fast—the initial implementation isn’t all that hard. But you can learn a lot from the slow implementation and it has some value to a user who wouldn’t otherwise be able to do the action in the story. In this case, break the story into “make it work” and “make it fast”:

As a user, I can search for flights between two destinations.
…(slow—just get it done, show a “searching” animation).
…(in under 5 seconds).

Pattern #8: Operations (e.g. CRUD)

The word “manage” in a user story is a giveaway that the story covers multiple operations. This offers a natural way to split the story. For example:

As a user, I can manage my account.
…I can sign up for an account.
…I can edit my account settings.
…I can cancel my account.

Pattern #9: Break Out a Spike

A story may be large not because it’s necessarily 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 or have a better idea of how to break it up. Don’t know how to implement the following story?

As a user, I can pay by credit card.

Then, break it into:

Investigate credit card processing.
Implement credit card processing.

In the “investigate” story, the acceptance criteria should be questions you need 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.

Conclusion

Resist the temptation to split an overly large user story by architectural layers. Instead, try these patterns to split your story into smaller stories that still satisfy the INVEST model.

Five Story-Splitting Mistakes and How to Stop Making Them:

#1. Treating Story Splitting as Just the Job of the Product Owner

While splitting should not be viewed as solely the responsibility of the product owner, the product owner should be involved in splitting. The responsibility should not be given over to the development team alone. For stories to be split in an optimal way, the product owner does need to be involved.

This means story splitting should be viewed as a whole-team activity. That doesn’t mean the whole team has to be involved in every split. Rather it means that splitting isn’t delegated to one or two people on the team who do it for every story.

Instead two teammates may join with the product owner to split a story or two. Later another team member and I might help the product owner split the next story.

#2. Splitting Stories along Technical Boundaries

Often these are the stories that get written as, “As a programmer, I want…” and describe functionality from the viewpoint of the team rather of an end user or stakeholder.
Splitting along technical boundaries can lead to stories like:

As a user, I want a backend that does such-and-such
As a user, I want a frontend that does the same such-and-such

A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own. A frontend (say, a web interface) does users no good until it is paired with a backend (a middle tier and/or database).

To avoid falling into the trap of splitting a story along technical boundaries, see if you can instead split the story based on the paths through the story.

To split a story on its paths, think about the paths through the code the team will write. There’s often a happy path, that defines what occurs if all goes well. There is usually also a path for each error that can occur.

You can also think about the paths a user may take in performing the story that needs to be split. For example, consider a sample story of paying for the items in a shopping cart, since that’s an example that would apply to any eCommerce site. In checking out, the buyer can select a shipping method—perhaps choosing between overnight delivery, two-day delivery, or a slower delivery.

Since choosing a shipping method will add to the effort to develop the story, consider leaving that functionality out of an initial implementation. Perhaps a first version assumes everyone gets slow delivery with no option for faster shipping. Developing just that path through the implementation simplifies the user interface (there’s no need to allow a user to select shipping options), reduces the number of cases to test, and so on. Splitting by path would be a very viable option in a situation like this.

#3. Specifying the Solution as Part of the Story

The best user stories will focus on what needs to be done rather than how it will be done.

For example, right now I have a picture I want to hang on my office wall. If I were to ask someone to do it for me, I could tell them how I want it done. I could say I want it hung using a ⅜” mushroom head toggle bolt. I’ve very much specified the how if I do that. Unless the exact details matter to me, I’d be better sticking to what I want: “I’d like this picture safely hung in about that spot on that wall.”

Including the solution within a story tends to happen when stories are being split too small. Once a story gets to a certain small size, there isn’t much more to say about the story and implementation details start to creep in when they shouldn’t.

#4. Using a Spike on Every Story

A spike is an effort undertaken by a team to develop new knowledge rather than new functionality. Spikes are often used to reduce the risk or uncertainty on a story. If a team is unsure about or unfamiliar with a new technology, they may run a spike so that they can learn more about the technology.

Splitting a spike out of a story can be a good approach. It reduces the uncertainty in the initial story, which will likely make the story take less time to develop. But running a spike may also help a team and product owner discover new ways to better split the story if it’s still too large after the spike.

So, extracting a spike from a story is a good idea in some cases. But the mistake some teams will make is becoming over-reliant on spikes. Some teams will go so far as to split a spike out of every story.

Bad idea.

Spikes are most useful when a story includes an excessive amount of uncertainty, and when the team and product owner agree that uncertainty should be reduced before implementing the story. A spike should not be used when a story has an everyday, common amount of uncertainty.

Uncertainty exists to some extent in every story. Will users like this if done that way? Will this design perform adequately? Will this new tool perform as well as the vendor said it would? These, or ones like them, are questions that exist in every story. The goal of a spike should not be to eliminate all uncertainty. In most cases, that would be impossible anyway until the final line is written.

Instead, spikes should be reserved for when a user story contains so much uncertainty that starting the story in earnest would be a mistake without the knowledge to be gained from the spike.

Teams that split spikes out of stories too frequently often do so out of fear of getting an estimate wrong. The team feels like they’ll be punished, or at least criticized, if a story takes longer to develop than they estimate. To overcome this problem, either de-emphasize estimates or work to create safety around them so that teams don’t fear each estimate will used against them.

#5. Thinking All Business Rules Need to Be Enforced from the Start

Sometimes a user story is made difficult to implement because of rules the story must comply with. These are often called business rules because the business’s operation is usually the source of them. Other times, though, they can be thought of as rules imposed by the system. Let me illustrate this with an example.

Suppose you are on a team working at a bank that makes mortgage loans. Your team is developing a new mobile app that the bank’s customers will use to apply for home loans. Perhaps a rule in place at your bank is that no one can have more than $10 million in outstanding home loans. This rule applies whether the borrower wants one big loan or now wants a $6 million loan on a second home in addition to an existing $5 million loan.

Your team’s new mobile app will ideally enforce this maximum by not allowing a person to submit a loan application that would exceed $10 million in total loans (whether this is the borrower’s first, second or tenth loan).

A rule such as this will increase the effort to complete the user story because the new mobile app will need to look up the existing loan balance, add it to the requested loan amount and make sure the sum does not exceed $10 million.

If this rule makes the story take so long that it will not be feasible to implement the story within a single iteration, the rule should be relaxed (or removed) in the initial iteration and then added back in a subsequent iteration. And, no, the team shouldn’t release a product that violates business rules (temporarily).

The mistake I’ll see teams make is thinking that all such business rules need to implemented right from the start. This often leads a team and product owner to instead use a less desirable way of splitting the story.

In the next meeting in which you’re splitting stories, look for ways to partially implement a story by not supporting a rule initially. As long as you don’t intend to release that iteration’s finished work, you’ll find that relaxing rules can be a great way to split a story.

References:
https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes-and-how-to-stop-making-them
https://www.leadingagile.com/2015/06/story-splitting-where-to-start/
https://agileforall.com/resources/how-to-split-a-user-story/