8 Techniques for Splitting User Stories

In my post, The Everything User Story Guide: Tips and Tricks for Writing Better Requirements, I touched on Splitting User Stories and promised a post that expands on this topic. Here it is.

To split or not to split – that is not a question that is easily answered.

In the User Story universe, there is much debate about what level of detail is “right”. The answer is simple, really – it depends. First and foremost, the right level of detail for any User Story is a level that allows developers to deliver code that implements the intent behind the Story with high confidence.

That is why the “S” in the well-known INVEST model is so important (S stands for small). But how small is small?

The only folks who can answer that question are those assigned to the development team. Their ability to understand the intent depends heavily on their collective experience with the problem domain, the organization, and the technology being used.

• More experienced teams in all three dimensions can deal with relatively complicated User Stories with no problem.
• Less experienced teams will need a lot more detail to feel good about what they are expected to deliver.

Because “small” is relative, many User Stories must be split into smaller chunks to ensure that the developers’ needs are accommodated. The idea of “Splitting” a User Story into multiple, simpler (ergo smaller) User Stories is very common.

So, given that you need to split a User Story, what techniques could you use?

Splitting User Stories: Technique 1 – Focusing on a Single Thought

When a User Story contains conjunctions like “and,” “but,” or “or,” it can often be broken down into several simpler Stories that each describe a single action or component. An exception is when you use the conjunction just to list items. However, when you use it to connect main and/or secondary clauses, the Story becomes unnecessarily complicated and can be easily broken down.

To see if a Story is suitable for this technique, check to see if the conjunction on either side of the word “and” appears with different subjects, verbs and objects—in other words, a compound sentence.

User Story example 1:

As an applicant, I can navigate to the coverage screen, enter personal and vehicle data (connected data), and submit the application (compound sentence) online to request automobile insurance coverage.

To make this simpler, split it into multiple Stories:

• As an applicant, I can navigate to the coverage screen to select the insurance coverage I need.
• As an applicant I can enter personal and vehicle data to calculate the premium.
• As an applicant I can submit an application online to request automobile insurance coverage.

This is one example of how to make a User Story simpler by breaking it down or splitting it. This way, it is easier to understand and less subject to misinterpretation.

Splitting User Stories: Technique 2 – Deliver Incremental Business Value

Sometimes a complex User Story, Feature or Epic can be decomposed into several User Stories to deliver the business value of the original Story gradually over multiple iterations.

User Story example 2:

To enhance knowledge sharing, instructors can assign students to groups dynamically ensuring that each group has a balanced set of skills needed to complete each exercise.

Could you split the Story to do that simple core first and enhance it with later Stories? How about:

To complete exercises, instructors can allow students to work in groups.

That is a simple User Story that delivers significant business value. Once that works, subsequent iterations could deliver the remaining 4 User Stories:

• To balance the set of skills needed to complete an exercise, instructors can
  dynamically change the makeup of groups.
• To optimize the learning experience, instructors can define the skills necessary to complete each exercise.
• To build effective teams, instructors can capture the skills each student has.
• To build effective teams, instructors can match the combined skills of student groupings to the skills necessary to complete the exercise.

Here are a few more techniques for splitting User Stories.

Split User Stories by User Roles

Sometimes, the best way to split a User Story is to examine the different types of users the user role represents. How will they use the final product? Each unique need can be addressed in a different Sub-story. When you break down Stories based on the needs of each new user role, you will find that most of the effort goes into one Story and the others will have only small adaptations. This is perfectly fine.

Split User Stories by Acceptance Criteria

You can break down large User Stories by using the Story’s Acceptance Criteria as your guide. This way, it becomes much easier to plan and implement smaller Stories independently. Not only do you get more flexibility and agility, but you also get a bonus in terms of quality control: You can review each Story independently. If a given User Story turns out badly or does not go according to plan, it will not take down the rest of your release cycle or affect other features.

Split User Stories by Data

Sometimes, the complexity in a User Story is caused by the variety of data types that are involved.

For example, we were working with a client on a new application that would help golf course professionals score tournaments. The application needed to support many different types of competitions — individual stroke play, team play, match play, and more — each with their own set of rules for scoring the tournament. This was an excellent example of where we had to split the data types into separate User Stories to deliver initial functionality and then enhance it at a later point.

Without this structure, the complexity would have been overwhelming for the team. There were too many data types for us to consider all at once. We were able to deliver something useful in small increments, allowing us to collect feedback from our users during each delivery cycle until we were able to get something that was valuable enough for them to adopt as part of their routine.

Splitting User Stories by Business Rules

Breaking down a User Story by Business Rules is another great way to right-size your Story. A Business Rule is a statement that tells you how to run your business; it guides your business practices, so if multiple Rules are present, they can be implemented as separate Stories.

But beware! Only some Business Rules can be implemented independently while others cannot. If a Rule is not independent, you will have to figure out whether it can be done in isolation or if it depends on another Rule to function correctly.

Splitting User Stories by Workflow Steps or Events

The idea of splitting a User Story or Epic by workflow steps is simple:

1. Find the fewest number of workflow steps needed to deliver business value to the end-user
2. Create a Split Story for those steps
3. Move the remaining steps of the workflow to future releases.

However, if you have ever tried to split a Feature, Story, or Epic by workflow steps, you know how tricky it can be.

For simple workflows, we recommend a technique called “Sequence of Events.” It works like this: You ask your end-users to walk through the events that happen (workflow steps) in their head and write them down on a piece of paper. Tell them not to worry about whether the steps are sequential or not, you just want to hear them all.

For example, for an event planning product, we got this Epic that needed splitting:

As Event Manager, I can arrange for all facilities online to optimally support the event.

After talking to the SME, we wrote down the following business events:

• Contact performers (artists)
• Capture performers’ venue requirements
• Research potential venues
• Compare venue availability, cost, and features
• Select best-fit venue
• Schedule event with venue and performers
• Add event to EventBrite
• Monitor ticket sales

One way to split this Story would be to create a User Story for each event, then decide whether the resulting Story deliver sufficient value to be stand-alone.

After evaluating, we decided that “Contact performers (artists)” alone would not provide enough business value, so we combined it with “Capture venue requirements”. This resulted in the User Story:

As Event Manager, I can get venue requirements from the performing artists to ensure that the facilities I book work for them.

That Story definitively has value to the event manager all by itself. We moved the remaining User Stories into future iterations.

This method is great for simple workflows where you can predict what will happen next. But if you have complex processes with lots of exceptions and other unpredictable behaviors, you might need to do a bit more analysis.

That is when Process Modeling experience comes in handy! If you know how to create Activity or Swimlane Diagrams, Data Flow Diagrams, or some form of process model, you can analyze which set of processes or functions delivers value to the end-user.

Splitting  a User Story by Use Case Paths

If you are familiar with Use Cases, another option to break down a User Story is splitting it along Use Case paths. Each path through the Use Case makes a great stand-alone Story.

Even if you currently have no Use Cases but need to split an Epic or an overly complex User Story, developing a high-level business Use Case may be the best choice.

Create a Use Case for the Epic or complex User Story, then write one User Story for the Standard Path and one or more for each of the Alternate and Exception Paths. If the flows are too large for the next iteration and need to be split further, use the workflow analysis we described in the workflow splitting method.

Once your User Story is properly sized and ready for programming, the next step is to write Acceptance Criteria.

Last Thoughts

So, the answer to “how can I make my User Stories smaller” is simple. Pick a technique that resonates with you and break your next set of Stories down using it.

It won’t be easy, and don’t be surprised if you run into some resistance along the way. But by breaking Stories down in this manner, you will ultimately enable your team to provide better estimates, more accurate iteration planning, and the best chance at developing clean code.

Ultimately, any approach you take will likely be suitable. But regardless of how you arrive at your Stories, a word of advice: do not lose sight of why you are creating these smaller Stories.

If a new functionality ends up being too convoluted to describe with a single User Story, it is an indication that something is wrong; given time and resources your developers can easily split more User Stories out of these existing ones.

Thank you, everyone, for reading this. I hope it’s been helpful.

Now, I’d like to hear from you: have you found other techniques that have worked for you? If so, we’d love to hear about them.

Please share your comments, insights, suggestions, and thoughts below!