Patterns for Splitting User Stories

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.

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. 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 3/2012: Check out the new story splitting resource I’ve created to help you apply these patterns on your stories.

About Richard Lawrence

Richard is partner at Agile For All and an agile trainer and coach. He helps teams and organizations become happier and more productive. When Richard's not working with teams, he's usually on his mountain bike with his wife and three boys.

Comments

  1. Steve Quince says:

    Great advice and excellent cheat sheet. Thanks for the post.

  2. Nick Pye-Smith says:

    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.

  3. @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.

  4. Mike Lowery says:

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

  5. 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!

  6. Excellent resource, Richard!

  7. Asim Ghaffar says:

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

    • Richard Lawrence says:

      @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!

  8. Reefa Mary says:

    Excellant ! thank you Richard.

  9. 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,
    Damian

  10. 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?

    • Richard Lawrence says:

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

  11. @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 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.

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

  13. Good post Richard!
    I have created an acronym to be used as a complement to INVEST with similar ideas as the ones you describe here. I find that many teams have a lot of issues with splitting stories so it is a topic worth exploring.
    I call it Splitting User Stories SOUND advice (which I hope it is…):
    http://agile-management.com/wordpress/splitting-user-stories/

  14. 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?

    • Richard Lawrence says:

      @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?

  15. @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.

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

  17. Hi

    Nice post.

    Have you looked at Feature Injection? http://www.infoq.com/articles/feature-injection-success I think your patterns would fit nicely within the structure of feature injection.

    Also, have you seen Nader’s post on INVEST and MOSCOW? http://nadertalai.blogspot.com/2011/05/why-i-wont-invest-in-moscow.html

    Regards

    Chris

    • @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.

  18. sery0ga says:

    Hello Richard,

    Thanks for a great post.

    I’ve translated this article as some of my team members don’t know English good enough and it helped a lot. I want to publish translated version so others can get use of it too.

    Would you mind if I publish this post and another one (http://www.richardlawrence.info/2011/09/02/why-longer-sprints-probably-wont-help/)?

    Cheers,

    Sergey

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

  20. Great post, thanks a lot

  21. 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!

  22. 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?

    • @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.

Trackbacks

  1. [...] This post was mentioned on Twitter by Rich Wand, Richard Lawrence. Richard Lawrence said: Just posted "Patterns for Splitting User Stories" (with cheat sheet) http://bit.ly/3IlxHI [...]

  2. [...] Patterns for Splitting User Stories [...]

  3. [...] we can estimate the amount of work we can finish in a given amount of time. The next ingredient is breaking down user stories to such Kanbans of 1 to 5 DPs [...]

  4. [...] stories. Next to some good examples in the mailthread, Charles Bradley also provided a link to Patterns for Splitting User Stories by Richard [...]

  5. [...] personas. This post also touches on the development efficiency issues. Another great post is from Richard Lawrence’s blog and gets into much more detail about some patterns to follow when splitting stories. If anyone else [...]

  6. [...] zerteilen können. Dazu gibt es diverse Verfahren, die z.B. Richard Lawrence in seinem Blog-Artikel Patterns for Splitting User Stories beschreibt und die auch auf Tasks anwendbar [...]

  7. [...] See Richard Lawrence’s great post on patterns for splitting user stories. [...]

  8. [...] die Hinweise zum Zergliedern von User Stories mit den Verweisen auf Richard Lawrence, Lasse Koskela und Bill Wake finde ich hilfreich und im Artikel sehr gut [...]

  9. [...] http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/ This entry was posted in Uncategorized. Bookmark the permalink. ← Slicing and Dicing Epic User Stories – Agile Coaching LikeBe the first to like this post. [...]

  10. [...] you want to dig deeper into the subject try Richard Lawrence post on Splitting User Stories for a slightly different take and more examples. Agile Requirements ← Agile vs [...]

  11. [...] Splitting user stories which are too big (☼). [...]

  12. [...] статьи Ричарда Лоуренса «Patterns for Splitting User [...]

  13. [...] статьи Ричарда Лоуренса «Why Longer Sprints Probably Won’t [...]

  14. [...] Ways to Split User Stories 15 Ways to Split an Epic, a Team Exercise Twenty Ways to Split Stories Patterns for Splitting User Stories Non-functional Requirements as User Stories — как превратить [...]

  15. [...] Stories.” XP123: Exploring Extreme Programming, December 2005. [2] Lawrence, Richard. “Patterns for Splitting User Stories.” October 2009. [3] Rainsberger, J.B. “Splitting Stories: An Example.” June 2007. [4] [...]

  16. [...] Darstellung. Hintergrundinformationen zu den einzelnen Pattern bietet Lawrence dazu auch nochmal in seinem Blog [...]

  17. [...] If you are serious about your user stories, there is a great article by Richard Lawrence about patterns for splitting user stories. [...]

  18. [...]       Patterns for Splitting User Stories http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories Share this:ShareTwitterLinkedInTumblrGoogle +1FacebookPinterestRedditDiggStumbleUponPrintEmail [...]

  19. [...] teams to cut stories down. It’s a skill that grows with practise. People not accustomed to splitting stories into nice vertical slices tend to think it’s not possible. And they often don’t see the [...]

  20. [...] user stories is breaking them down to the right size. Richard Lawrence has written an excellent pattern language to help you in this [...]

  21. […] that include some details that are left out of the reference.  Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence.  See also the great foundational article on “INVEST in Good […]

  22. […] 2009 Richard Lawrence made the lives of (agile) teams easier by describing patterns of how to cut down chunks of work into smaller, still valuable chunks. In 2012 he followed up with a Cheat Sheet that summarizes the patterns. Print it out and go slice […]

Speak Your Mind

*