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