Skip to content

Splitting User Stories: Techniques

    This is part 2 of a 3-article section dedicated to splitting User Stories. PART 1 – PART 2 – PART 3.

    Story splitting techniques

    If you do a Google search for “techniques to split user stories”, you will find a variety of different techniques. Some people say there are 7, some people say there are 9, some people say there are 25 different techniques. The point is, there are many different techniques.

    I have listed the most common below and I am going to explain a few with examples.

    I invite you to experiment with these techniques, and find those that suit your needs the most. In the end, you may create your own personal “menu” of splitting techniques. For example, I have my short list of 3 or 4 favorites that I always use when splitting stories.

    ConjunctionsLook for words like and, or, but, etc. and split in two or more parts at the point of conjunction
    Acceptance criteriaSplit in multiple stories, each story with only a subset of the acceptance criteria from the original story
    Workflow stepsIdentify the different steps the user goes through, and break into multiple stories, one for each step in the workflow (also CRUD)
    Variation in dataWhen different types of data are presented to the user, they can be used to split the story, one story for each type of data
    Variation in interfacesBuild first the web version, then the mobile version, then add support for tablets
    Business rule variationIn situations when business rules change, split the story for each rule
    ScenariosWhen a story covers multiple scenarios, split it for each scenario
    Happy pathIdentify the happy path and create a story for that. All other conditions can be split in a separate story to cover the unhappy path.
    By User PersonaEach Persona may have different needs. Create a story for each Persona, rather than aggregating all into one story
    Breakout a spikeA research spike or a technical spike can be onerous. Find ways to break it into smaller chunks.
    Timeline analysisAnalyze what happens at different times of the customer journey, and divide the work for each time segment
    Defer performanceBuild first something easier or faster to build, and later add the complexity required to improve the performance or the security
    Simple/ComplexIdentify which parts of the story are easier to build and split them from other parts that may be more complex

    Let’s see some applications

    The Netflix examples used in this article are courtesy of Anil Jaising (CST) at Concepts & Beyond. Anil runs a User Story Splitting class. For those interested in learning more, please connect with Anil.


    The conjunction technique may sound very basic, but it’s actually very effective. It works in this way: when you read the story, do you see any conjunction? A conjunction can be the word “and”, the word “or”, or any commas. If you see a conjunction, you can split the story in two parts by diving it at the conjunction.
    For example:

    As a passionate user of Netflix, I want to get recommendations for romantic movies, international drama, and detective TV shows so I can enjoy my evening and forget work issues.

    Because we have 3 conjunctions there, we can split this story in 3 smaller stories, each one focused on just one piece of the work. We will have one story for romantic comedy movies, one story is for international drama, and one story for detective TV shows.

    Each one of these is smaller than the original story.

    Because it’s simple, the conjunction technique should be the first thing you do when you have a big story.

    Acceptance criteria

    You can also split a story by its acceptance criteria. Sometime the complexity of the work doesn’t come necessarily from the story itself, but it actually comes from a long list of acceptance criteria that we need to satisfy.

    Let’s see an example:

    As an avid social influencer, I want to share the shows I love so that I can engage my friends and family on social media.

    Acceptance criteria:

    • Make sure that we are able to share on Instagram, on Facebook, on Snapchat, and on Twitter.
    • The share button provides a confirmation after sharing.
    • Option to share automatically on multiple systems, so that we only need to press the share button once

    Notice that the story requires to share on multiple system, each one with its own complexities.

    The complexity here comes from the acceptance criteria. Therefore, if we divide the acceptance criteria between multiple stories, we can create smaller stories. We can create multiple copies of the original story, each with only a subset of acceptance criteria.

    For example, the first story can have the acceptance criteria only for Instagram. The next story can have acceptance criteria for Facebook, and so on. The confirmation part can be added in another story. And finally, the automatic sharing across multiple systems can be another story that we’ll likely do only after all the other ones have been completed.

    When we go and build this functionality, we can start on Instagram. When we are happy, then we can add the second story to have the functionality to share on Facebook. We keep building this functionality incrementally, one story at a time.  

    Looking back, we started from the big story with a lot of acceptance criteria, and now we have several smaller stories with a subset of the acceptance criteria. While the original story was too big and complex for a Sprint, the smaller stories can be done in a Sprint each.

    Workflow steps

    The next technique is called workflow steps. Sometimes the end user needs to go through multiple steps in using a functionality. For example, when you checkout on an e-commerce website, you may need to enter your shipping address, then the billing address, then the credit card, and finally validate all the information entered before completing the order. Each of these is a step in the workflow that the user needs to complete.

    When you have a big story, instead of building all the steps at once, you can build one step at a time. Maybe the functionality will be delivered to the users only once the full workflow is completed, but this doesn’t stop you from building one step, testing it, and then moving on to the next step.

    For example,

    As a passionate female subscriber on Netflix, I want to enter some basic attributes like my family name and a picture; pick different genres for movies, TV shows, and documentaries; view my choices, before finally submitting and saving my profile so that I can create my user profile in Netflix and share it with the world.

    Let’s split this by the workflow steps.

    1. The first step is for the user to be able to enter some basic attributes, like the family name and a picture. We will have one user story just for that. It doesn’t deliver the whole functionality, but this story delivers value to the customer because it allows the customer to enter their name and picture, and confirm that the system has saved them properly.
    2. Then we will have a second story allowing the customer to pick different genres for movies, TV shows, and documentaries.
    3. And then we will have a third story allowing the user to view her choices before finally submitting and saving their profile.

    If we do this, we create 3 smaller stories (each one small enough to fit in a Sprint) and we can potentially execute the work one story at a time.

    The workflow steps technique often is useful when you have CRUD situations. CRUD stands for Create, Read, Update, and Delete activities. For example, when you create a user profile; when you can read the user profile so you can show that to other users; when you update a user profile after it has been created the first time; or maybe when you delete the user profile or some parts of it. Each one of these activities can be split in a separate story. Using CRUD is another way to apply the workflow steps technique.

    Happy path

    Let’s look at another one, that is the happy path technique. What is the happy path? When we build a new functionality, there is a happy path: the user uses the functionality, and everything just works fine. The customer doesn’t make any mistakes, there is no data error in what they enter, the system works well enough. Everything is fine. That’s the happy path.

    In general though, the happy path is the “ideal” scenario, but the reality can be different. In fact, there can be a lot of complexity that comes from managing all the errors and the unexpected conditions. That is, all the possible situations that arise when the user enters wrong data, or does something unexpected, or the system cannot complete a task as planned. We need to manage all these error situations to make the system more reliable. That’s what we call the unhappy path.

    Because of that complexity, it could be useful to split the happy path from the unhappy path. So, you could create two stories: one assumes the happy path (no error condition, no unexpected events). The other story adds the complexity of managing the unhappy path (all the possible errors and unexpected conditions).

    Let’s look at an example:

    As a father, I want to set up parental controls and a pin so that my kids don’t watch movies that are too violent for their age.

    What is the happy path? The happy path is, of course, that I am able to set up parental controls and a pin, and the system here just lets me do that. It’s not going to check for any errors. It’s not going to check if the pin is the right one or the wrong one. It’s just making it work the way it’s supposed to work without checking any error conditions. My first story covers just the happy path.

    Then, I can create a separate story to cover the error conditions in the unhappy path. So, for example, when the user enters the wrong pin, what happens? In this case, I may want the system to show an error so that the user can correct the wrong pin. This is managing that error condition for the wrong pin. There is a complexity in managing that. We just separate it from the first story.

    We can also add a third story because there could be an additional level of complexity: When someone enters the wrong pin for 3 times in a row, I want the system to lock the account for 2 hours so that the user cannot try again to break the pin.

    By separating all these error-handling situations in different stories, we have created a set of smaller stories that are easier to handle compared to the original big story. Now, the work for each story is much easier and potentially can be done within a Sprint.

    Defer performance

    I would like to share another technique called defer performance. When you build a complex system, sometimes there is a level of complexity just to support the performance that you want to deliver. For example, if you want the system to do something and do that very quickly, or with high security, just adding the speed component or the security component may add its own level of complexity.

    In fact, we could split the functionality in two parts. First, we could build that functionality without any performance. For example, we may build it very slow or with no security. It works, it does what it is supposed to do, it just lacks the expected performance.

    Secondly, we can add the performance (the speed, or the security) in a separate story and get it done later.

    For example, we may have a login page where, first, the username and password are transferred in clear text. No encryption, no security, we just make the login work. And then later we work on a second story that adds the encryption on the password so it doesn’t show in clear text anymore.

    Let’s look at an example:

    As a busy professional, I want to start watching a movie immediately after I click play so that I don’t have to wait for the movie to load.

    Acceptance criteria:

    • “Immediately” means that it starts in less than 1 second after clicking play.

    There is a lot of complexity in building a system that is so responsive that it can start in just 1 second. Maybe we can defer that level of performance to a separate story.

    In the first story we could build the system without any performance concerns. So when the user clicks play, the system plays a movie and it takes the time it needs. In this story, time doesn’t matter. It may be super slow, but we want the “play the movie” functionality to work. Let’s make it work first.

    And then later, we can add the complexity that comes with the performance. We can add buffering or whatever other technology we need to make sure that the system works in less than 1 second.  We are deferring performance to a second story.

    By splitting the original story in two parts, each story is smaller than the original.


    The Netflix examples used in this article are courtesy of Anil Jaising (CST) at Concepts & Beyond. Anil runs a User Story Splitting class. For those interested in learning more, please connect with Anil.

    Agile for All created a mind-map for different splitting techniques. Download it from:

    Read more

    PART 1: Splitting User Stories

    PART 3: SPIDR Techniques