Patterns for Splitting User Stories

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.

MatryoshkaGood user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.

Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable.

Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories.

(Note: As with any pattern language, I didn’t invent these patterns, I’ve just observed and compiled them. For example, this great post by Lasse Koskela put names on some patterns I’d observed but not named, especially “Major Effort.”)

How Small?

How small should stories be? I recommend 6-10 stories per iteration, so how small is small enough 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. But on a recent project I’m doing by myself, I’ve needed to split 5-point stories.

When you’re in a planning meeting and you hit your trigger estimate, pull out the cheat sheet at the end of this article and 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? I use two rules of thumb:

  1. 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.
  2. 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. Check out this excerpt from my 80/20 Product Ownership course for more on why the obvious split is wrong and how to use the other two approaches.

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.

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.

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.


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. Let me know how it works for you or if you’ve run into unsplittable stories (I love a challenge!).

Download the Story Splitting Cheat Sheet

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.


Related Articles


  1. These are very helpful except that I can’t see a real difference between #2 and #4. Perhaps different examples would make the distinction clearer.

  2. @Nick – The big difference is that in Simple/Complex, the original story lives on as the simple version and new stories are created for enhancements on the simple version, while in Business Rule Variations the original story is replaced by 2 or more new stories that cover different business rules within the original story.

    I explain this much more when I teach the patterns in-person. Rereading the blog post, I can see how the distinction isn’t clear enough. Thanks for the feedback.

  3. Love this post, I have sent it to all of my co-workers as a “must read” on user stories

  4. Wow,

    I think I’ve found the Alandin’s Cave of getting more productive in projects. I never knew this whole field existed. I especially like Tip No.8 on Deferring performance. I have day-dreamed about this approach before but never seen it formally presented like this in an obvious and yet simple way.

    Thanks for sharing!

  5. I am stuck with one story… 🙂 that i am assuming will take at least 6 month to complete..

    Its like that we have a few scientific products.. and one of the product use flat files for persistence.. other products can use that data but one at a time..

    We cannot put the whole files in DB as its huge data.. 20GB+.. but still we have found a solution where some data can be put in DB.. e.g. user interpretations, meta info, markups etc..

    So the story is like:

    “As a user i can concurrently access product A data from product B, C and D”. Even if I keep it as “As a user i can concurrently access product A data from product B”. Its still huge..

    Even doing like following, Its still huge..
    “As a user i can concurrently access feature X of product A data from product B”.

    the problem is if you can do one thing (one feature, one product) you can do all..

    1. @Asim – Sorry, I don’t know enough about your particular product to suggest how to split your stories. However, it sounds like you’re splitting it without actually cutting through the complex part, the part that takes most of the time. Try identifying what it is that makes even the smallest story big and look for ways to do just a slice of that. Don’t worry at first about identifying all the slices—actually building one or two small slices may give you insight about how to split the rest. Good luck!

  6. Hello,

    i enjoyed your summary about user-stories and I´m also a big Fan of this kind of requirements engineering but in my actual position we´re still using the oldschool variant.

    The problem that i have with user-stories is to combine that with some deeper technical stuff. We´re developing enterprise solutions and defining such stuff like data models, interfaces with deep and detailed informations and in my point of view the user-stories do not reach the level of detail.

    Another thing is how to define non-functional requirements?

    Do you have some help for me, how to solve that with user-stories?

    Kind regards,

  7. Very helpful article! We’re running into a situation where some user stories are too large to fit into a single sprint, but only because of the length of time it takes for the art department to create an asset and get it approved. By the time they are ready to hand it off to the developers, there frequently isn’t enough time left in the sprint for the developers to integrate the asset. The “architectural layer” split method you mentioned has been suggested so that the art dept. does there work in one sprint and dev does their work in the next. Is there a better way to handle that?

    1. @Dale – Unless the work the art department does can be split and allow them to turn things around faster, this sounds like a case where they may have to work ahead of the development team. You might decide not to consider a story ready for the team to take into a sprint until any art assets are ready. Or, you might look for ways to reduce that turn around time (e.g. could you make the approval process lighter?).

  8. @Dale,

    If it’s hard to predict the art department’s turnaround time, then I coach teams to handle the art dept’s work as a Spike Story. A spike story is some work done to remove the unacceptable estimate uncertainty from a story. I recommend this strategy for most external dependencies that are not highly predictable from an estimate standpoint.

    I also concur with Richard’s possible solution of split work into smaller chunks — but ONLY if that changes the predictability of the turnaround time in the art department.

    I should also mention that spike stories should make up about 10% or less of all stories that you have. If you have more than that – it’s a bad smell that needs to be analyzed.

    1. +1 on the smell. I reckon spikes stink! If you can stick Charles’ 10% rule, then you’re probably OK, but watch out for the team that begins to *require* a spike before creating user stories or beginning at all.

  9. Richard and Charles:

    Thank you for your help! The problem isn’t so much the art department’s inability to estimate time required as the length of time they require for many pieces, which is just too long for the mandated two-week release cycle. We’re most likely going to have the art department work ahead.

  10. Hi Richard,

    How would you split a story which in essence is quite simple: just a search box that should display the results of what you typed in.

    The thing is that behind the scenes, we have to configure the search engine and create the interface with it and configure the build server. This is the first story so we decided to work on the build server effort as part of this first story.

    We prefer not to work on the so called story-less tasks since we prefer to track stories and not tasks, and don’t like the idea of “technical tasks” to setup an environment for example since I’m not confident in estimating those in terms of story points.

    Could we split the search textbox and results story in some way? What do you think?

    1. @Mac – The point of the story splitting patterns is to help you find the complexity in a big story so you can focus the split there. Without knowing all the details of your story, it seems clear that the complexity is not in the UI, but in the background activities that make the simple UI possible, so I’d be looking for ways to take slices through those. For example: What’s the simplest slice through the build server you could do to support this story? Is configuring the search engine an “all or nothing” activity, or could you do a simple configuration first and add more functionality with future stories?

  11. @Richard – Excellent guide to splitting stories. Most of the patterns you described split the story along nonfunctional lines. I.e., the functional part of the story remains largely intact across iterations, but the acceptance criteria are effectively strengthened for each iteration.

    The noteworthy exception is pattern #8. Pattern #8 splits an overarching CRUD type story along functional lines.

    And I’d argue, by splitting the story along functional lines, the pattern often violates the INVEST guideline. Specifically, it often renders the fractured stories not valuable to customers in isolation.

    For example, creating data in and of itself is usually not valuable; users want to do things with data. Same for updating and deleting data, and, in many cases, retrieving data. I don’t really want to add an entry to my checkbook; I’d rather it happen automatically. (Better yet, I’d like to know that my bank is tracking everything properly and that I am not overspending.)

    As a general rule, I favor the other patterns you’ve mentioned for splitting stories. There are a lot of interesting issues surrounding splitting stories that I explored in this blog entry. I’m curious what you think.

  12. Our team has pretty much turned away from Agile and determined that splitting large stories means dev in one sprint and qa in the next sprint. I.N.V.E.S.T. is discussed but not really considered when splitting stories.

    Some stories are dependent by nature, for instance when a story has downstream or up stream effects on otehr teams.

    1. @Chris,

      Thanks for the comment and for the links.

      The way I teach teams to use the patterns to slice an MMF and then prioritize slices that provide the most value, learning, and/or risk mitigation seems to have a lot in common with Feature Injection. I’ll have to look into that more.

      Regarding the INVEST/MOSCOW post…Totally agree on MOSCOW; I haven’t found value there for years. Even within an MMF, though, I still find INVEST a useful tool. While the INV attributes are much less important for a short time horizon (such as for the stories in an MMF under active development), it’s still useful to work those stories in an order other than one imposed by technical dependencies, it’s useful to have room to learn and negotiate details during development, and it’s good to be reminded that stories should be valuable slices through an architecture (even if no particular story brings enough value to be marketable on its own). I probably should do a post on the way I use INVEST.

  13. You lost me at the start of point 1, when you said your client was creating a Content Management System. I think from that point on everyone’s time and money is being wasted.

  14. Excellent post – I have been an advocate of Story Mapping as a technique – but teams always get stuck with “how” to actually split the stories – these patterns (and excellent flowchart!) provide the answer – thank you!

  15. Richard,

    First of all, excellent article and really helpfull, but (yes BUT) I have one big concern about pattern #3 (Major effort).

    It seems that it contradicts not only the point of stories being independent, as you mention, but I cannot think of a single example where the splitted stories would have a similar size, since the one taking the major effort would always be way bigger than the rest.

    I might be wrong, but I would discard this pattern altogether, wouldn’t you?

    1. @Matias – Major Effort is for when you have multiple variations where they’re all the same size except for whichever you do first, which is larger. In order to get them more equally sized, we group the pieces other than the first one rather than splitting them all. In order to get them more independent, we defer the decision about which variation comes first.

      Major Effort often has to be used with another pattern. In the credit card example I gave above, the first card might be 8 points and other three cards might be 1 point each. If we group the latter, they’re still only 3 points. We may have to apply another pattern to the first story to get it smaller than an 8.

      Finally, a note on independence: For a short time horizon, independent matters less than small. I can handle some dependency among stories in the next week or two. If story B depends on story A, I just won’t start B until A is done. It’s problem when we’re talking about several weeks or months out. Since story splitting mostly happens at the top of the backlog, many of these patterns give up some independence to get smaller stories, but this doesn’t bother me much.

  16. Hi RIchard,

    I really liked the material you shared here on this thread but I can clearly see this working fine whenever we talk about a given standalone application, where it is easier to split that. My main question comes whenever we try to see that on BI systems, where normally what you have is a given source DB, some ETL (jobs), a given target DB and then your final report.

    Ex: Assume you have a system where today they are returning only Active employees to a given BI system and there is a new user Story where the business wants to bring Termed employees as well.
    Assume here that the current logic behind is really complex to populate target tables.

    How you can suggest to split these kind of scenarios where we have a complex logic behind the scenes but the business need is really clear where it’s hard to get splt?

    Any suggestions are appreciated.


    1. For BI projects, I like to work from the questions our end users are trying to answer. That gives me an idea of where the value of the new project/feature/story is. Then, I’ll look at what makes it big. From there, I’ll look for a small story that will give me some of the value (i.e. answer a key question) without all the “bigness.”

      In your example, what’s the burning question about Termed employees that’s driving this story? Maybe there’s a way to start answering that question without taking all the complexity on the ETL side.

      Working incrementally requires a willingness to let the design emerge and change over time. Particularly in BI, I see a strong tendency to want to get the final data model on day one. This inevitably makes the first story in any new area a huge one. You’ll have to break that tendency if you’re going to find small stories that get you early value and feedback.

  17. Hi Richard, great article, thanks for sharing. I use all your patterns and some others too.

    I’ve discovered over the years that I tend to apply the different story splitting patterns in (roughly speaking) a specific order – some patterns apply more to larger stories and other to smaller stories.

    I also tend to try to avoid spikes – too many times they have turned into unbound excuses for developers to tinker…so I prefer to try to find a thin vertical slice that allows the devs to prove the architecture but also delivers something tangible, bounded and demonstrable.

    If you’re interested, my musings on the topic are at

  18. Hi Richard, it’s been almost eight years since you posted this, but it still is valuable! Thanks for keeping it online. I learned a lot. And thanks for creating the cheat sheet pdf. I’ve set it as my desktop background image 🙂

  19. Three suggestions the work with user stories
    1. Be clear about the DoD
    2. As a team; validate that user stories seem more behavior scenarios, than functional requirements. That is, asking questions about how to interact with the application and not how the application responds (and on what the tests are designed). That is to say, the user does when filling out a form or because of the relevant information and to avoid questions that should be answered or made by the application; the above oriented the test scenarios to identify the *Given* that the user needs _x_, *When* is doing _y_, *Then* what should happen is _z_.
    3. On the above, create the acceptance criteria for the stories
    4. Bonus: Line up those steps to

  20. Great article, thanks! I wonder if another way to split would be by type of device? mobile, desktop…..?

  21. Pattern #4 could also include Zero-feature releases as an extreme case (Extreme Programming). It is very useful to be able to verify the delivery pipeline as early as possible.
    “As a user I can reach the website (“Hello world”)”.

  22. […] Split The Story: If you didn’t heed the advice from Step 2, let’s review. It is essential to stick to one action per story. The idea is to break the stories down into iterations. By breaking down user stories, you can deliver smaller portions of the project that will give value to the customer. Splitting stories can be done in many different ways.  […]

  23. Richard! According to your opinion, what is the real difference between user story and another approach called use cases model descriptions?

  24. in your CRUD example which story (beginning with …) would come first?

    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.

    Thanks, great article

    1. Splitting gives you the option to go value-first or learning-first instead of technical-dependency-first. You and your team might have to get creative, though, to break out of the obvious sequence (e.g., if you wanted to do read before create).