Back to List

What are Agile User Stories and Why Should You Split Them?

Rachael Wilterdink Rachael Wilterdink  |  
Feb 04, 2020
 
Story splitting is one of the most deceptively difficult skills to master in agile. It sounds so easy, “Let's just a break a big story part into smaller pieces.” But as easy as it sounds, I struggled with it when I first transitioned to agile. I have since seen many other teams and individuals struggle with the same issue at many client organizations.
 
This blog series will dig into 25 different techniques for approaching story splitting. No one way is necessarily right or wrong or is the best option. There may be a whole lot of trial and error - which is okay. Admittedly, there is also some overlap in a few of these techniques. I have used most (if not all) of these approaches at some point in my agile career.
 
Some experts will say this list provides far too many options for story splitting, and that it would be better to keep splitting options to a narrow set of tools that can be consistently applied and easily remembered. After having researched numerous articles, blogs, eBooks, videos, etc. on this topic, I am somewhat split (pun intended) in my opinion. I would rather have more tools available to solve problems than less. This will ensure that I'm picking the best solution to my problem.
 
As a teaser, here is a list of the splitting techniques I'll be reviewing in this series:
 
  1. Capabilities / User Goals
  2. Workflow Steps
  3. Happy / Unhappy Path or Flow
  4. CRUD Operations
  5. User Roles
  6. Test Cases / Acceptance Criteria
  7. Business Rules
  8. Devices / Platforms / Channels
  9. Data Variations and Boundaries
  10. Spikes
  11. Simple to Complex
  12. Non-functional Requirements
  13. Bronze-Plated Flow Versus Gold-Plated
  14. Dummy Data then Real Data
  15. Static then Dynamic Data
  16. Manual then Automated
  17. Zero > One > Many
  18. Split Conditions
  19. Major Effort
  20. Error Handling and Logic
  21. Interface Variations
  22. Low-fidelity then High-fidelity
  23. Build versus Buy (and Buy versus Build)
  24. Vague or General Words
  25. MVP (Minimum Viable Product) then Enhanced
 
But before I get started on spelling out the story splitting techniques, I’m going to cover the basics in two blogs.
 
Today, I'm going to review:
 
  • The basics of what a User Story is
  • Horizontal vs. Vertical slicing
  • Why split stories?
 
And next week I will explain:
 
  • What makes a good user story?
  • How to identify bad user stories (aka Story “Smells”)
 
I hope you will join me on this journey as I explore one of the trickiest skills to master in agile.
 
P.S. Are there any other methods you have used to split stories that are missing from this list?
 

What is a User Story? 

There are many misunderstandings about what a User Story is, and I’d like to clear those up before we start talking about splitting them in meaningful ways. Very simply put, a User Story is a desired capability of a system, written from the perspective of a user, which is valuable to that user.
 

How do I write a User Story?

There is a typical format that most agile teams use, but this is not prescriptive, so you may see items that are not written in this way. This is the most common method:
 
As a <some type of user>
I want <something>
So that <I can achieve some goal or benefit>
 
For example:
 
As an avid baker
I want to search all my cookie recipes
So that I can figure out what cookies to make for my kids today
 
That seems straightforward, doesn’t it? Well, it’s deceptively simple, and much more complex than it seems, as you will soon see.
 

Are there alternative ways to represent a User Story?

Yes, there are. While the above format is common, you could express stories at higher levels, such as features or epics.
 
Epics would represent really BIG ideas, and could be written as a single word, such as:
 
Recipes
 
Epics can be further broken up into features (which we’ll dig into a bit more in a future blog), but can be written as actions/functions (often expressed as verbs) that can be applied to the Epic, such as:
 
Search
View
Manage
Share
Filter
 
The point here is that these all represent User Stories, but they’re at different levels. It doesn’t really matter what you call them: the key is that as you break them down into smaller chunks, they should become more clearly defined.
 
To recap the levels:
 
agile epic feature user story
 
There’s another level involved, which is when items are pulled into a Sprint Backlog and the team breaks the stories down into tasks – but that’s another topic for another day.
 
Another element that I won’t go into today is the corresponding set of Acceptance Criteria that results from having a conversation about the story. That is an essential part of having a complete User Story and will come into play when I start discussing the different methods of splitting. But for now, you know the basics of what a User Story is, and the most typical ways of writing them.
 

Who writes the User Stories?

Ideally, stories are written with collaboration from the Product Owner and Development Team members, often facilitated by the Scrum Master. Anyone can contribute, but that doesn’t necessarily mean that every story will be prioritized by the Product Owner to be developed.
 

When are User Stories written?

Just in time. You don’t want to get too far ahead of your team, or things are likely to change. If you have a product skeleton built, with the high-level epics and features, that will provide you with a good framework for deciding when to break items into smaller chunks (User Stories) that can be completed within a Sprint.
 

Horizontal vs. Vertical Slicing

A lot of newer Scrum or agile teams struggle with getting stories sized "just right". Large stories can be difficult to decompose into smaller bite-size chunks that can be completed within a sprint. Teams also struggle with the concept of "slicing the cake" or taking a vertical cut through all the technical layers. Understanding this concept is of key importance before we can move on to different ways of splitting up stories.
 

What does it mean to “slice the cake”?

It means taking a vertical slice through multiple architectural layers, rather than fully building each horizontal layer in sequence.
 
In the following illustration, you can see how a vertical slice cuts through all the technical layers, but it’s a small set of functionalities, delivered incrementally. Instead of waiting until all horizontal layers are built, you deliver a subset of working software that has value to the users much, much sooner. They may not have everything all at once, but they have enough that they can test it out and give you feedback.
 
slicing the cake - user stories
 
This is a really hard thing to do, and it’s hard to get used to doing. A lot of teams I’ve worked with eventually fall back into bad habits and revert to building out the horizontal layers – even going so far as to write so-called “technical stories” or tasks for each horizontal layer. This is not the best approach in agile and should be avoided.
 
Stories should be written from the customer or end-user perspective, including the “who”, “what”, and “why” to ensure they deliver business value. By slicing your stories vertically, you will ensure you are delivering on that promise to provide smaller pieces of value, sooner.
 

Why Split User Stories?

The simplest answer is that they are too big to complete within a single Sprint. If that’s the case, then you will have to find a logical way to split it into smaller pieces – some of which would then be right-sized to get to “done” inside of a Sprint. But how do you approach splitting up a big story into smaller ones? There are numerous approaches that I will dig into in this blog series.
 
Another answer to why stories need to be split is because they are too complex or complicated. There might be too many steps, or it might be difficult to test.
 
Another reason might be because you don’t know enough about the story to even know where to begin to meet the business need described, and you need to do some research first.
 
One other reason to split stories is to get rid of something that you can do without. It’s about getting a minimal marketable feature (MMF) or minimal viable product (MVP) so you can release to market and start getting feedback. If there are things you defer until later (or maybe never even do), you can focus on this highest value functions first.
 
You will also find that you may end up splitting or re-combining stories during your Sprint Planning. This is an art more than a science, and eventually you’ll figure out the splitting methods that work best for you and your agile team.
 

Practice, practice, practice

The more you practice, the more natural and intuitive story splitting will become. This is not something that you can study in a day and become an expert at tomorrow. I have been writing User Stories for many, many years, and I’m still discovering and learning new ways to split them.
 
Before diving into the list, next week we're going to cover a very important topic: knowing how to tell a good user story from a bad one. Make sure to subscribe to our blog or stop by each week to catch the latest installment in my deep-dive into 25 story-splitting techniques.
 
AgileScrum

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Agile Story Splitting by Capabilities/User Goals & Workflow Steps
Rachael WilterdinkRachael Wilterdink  |  
Feb 18, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   #1 - Capabilities/User Goals ...
Blog Article
How to Identify Good and Bad Agile User Stories
Rachael WilterdinkRachael Wilterdink  |  
Feb 11, 2020
If you read my previous blog, you’ll know the basics of a User Story. But what makes for a good or bad agile user story? In this blog, I’ll cover the criteria that will help you identify one from the other.   What Makes a Good User Story? The most common checklist that is...
Blog Article
4 Agile Transformation Pain Points with Managing Work
Rachael WilterdinkRachael Wilterdink  |  
Jan 28, 2020
In this blog, Rachael Wilterdink, CBAP®, PMI-PBA®, CSM®, PSM, pulls from her extensive experience to guide professionals along their agile journey. For a full overview on this topic, download her eBook: 20 Advanced Agile Transformation Pain Points.    As a Business Analyst with...
Blog Article
How to Form an Effective Agile Team: The Experts' Guide
Brian LaehnBrian Laehn  |  
Jan 21, 2020
In this actionable guide, Brian Laehn distills his 20+ years of experience as a Senior Business Analyst, Scrum Manager, Project Manager and Agile Team Lead.   Has your organization identified the need to create a new project team? You may be wondering what the best way is to form this new...
Blog Article
3 Agile Transformation Pain Points Managers and Executives Face
Rachael WilterdinkRachael Wilterdink  |  
Jan 07, 2020
In this blog, Rachael Wilterdink, CBAP®, PMI-PBA®, CSM®, PSM, pulls from her extensive experience to guide professionals along their agile journey. For a full overview on this topic, download her eBook: 20 Advanced Agile Transformation Pain Points.   As a Business Analyst, I...