Many new agile teams attempt to create stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy Small requirement, but it fails at Independent and Valuable (as part of the Bill Wake’s INVEST model).
Typically, large User Stories can be split using several of patterns. Here are two general rules of thumb in determining the right split to make:
- Choose the split that allows for de-prioritizing or throw away of a User 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. Rule of thumb is to go with the split that lets the team throw away the low-value stuff.
- Choose the split that allows 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 an example from a content management system: As a content manager, I can publish a news story to the corporate website, so that my content can be viewed by the public.
Didn’t sound too big—until you dig into the workflow to get a story published. It turns out that just to get a few sentence news story on the corporate website requires both editorial and legal approval and final review on a staging site. There’s no way a “story” like this would fit in one 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.
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, so that I increase the chances of a successful search.
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,” or …as “a weekend in December,” or …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.
This large story 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), or
…I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).
The two new stories still are not independent, but the dependency is much clearer than it would be with a story for each card type.
Pattern #4: Simple/Complex
During a planning meeting discussing a story, and the story seems to be getting larger and larger (“what about x?”; “have you considered y?”), the team needs to stop and ask, “What’s the simplest version of this?” Capture that simple version as its own User Story. The team will 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.
This story 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, consider a system needs to model geographic areas served by transportation providers. We could have burned our whole project budget just handing geography; it is potentially that complex. However, when discussing the story with the product owner this is the reworked request: As a user, I can search for transportation providers by trip origin and destination.
With the Product Owner, it was discovered that, while full-fledged GIS is not needed, modeling geography would still be quite complex. The team stopped and asked, “What’s the ‘good enough’ way to model geography so we can build other high-value features now?” The team settled on: As a user, I can search for transportation providers by trip origin and destination as counties.
This worked for a while, until more data was collected and it was determined 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, it was 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.
The key element to keep in mind is to keep the focus on value delivered, while splitting stories across acceptance criteria in such a way that the "core" story provides the minimal baseline for the delivery of that value, and subsequent stories serve to increase the robustness or user experience. Knowing where to start, and where to stop will maximize your returns.