Splitting user stories is an activity that allows to split large stories into smaller ones. Sometimes some work items are too big to fit in a Sprint, and we need to split them so that we can execute the work. Smaller stories also can accelerate the delivery of the work for a team.
Splitting User Stories
Let’s start with an example. The initial story is:
As a subscriber to Netflix, I want to cancel my subscription and then receive an email confirmation so that I’m sure the subscription has been canceled.
This story may be too big for a Sprint, and to help the team execute the work, we need to split it. There are a few ways that we can do that.
To start, we can identify different steps in the workflow: first, cancel the subscription, and then send the email. Therefore, we can split this story into 2 different stories reflecting the steps in the workflow. The first story is just about canceling the subscription. Then in the second story we can add the email confirmation.
If we split the original story in this way, the resulting 2 stories are smaller than the original one.
Let’s look at another example. In our business, we may have different types of customers. Maybe we have a yearly member, somebody who pays an annual subscription with us, and a monthly member who pays month-to-month. And for whatever reason, we have some business rules that allow a monthly member to cancel a subscription at any time, whereas an yearly member may only cancel a reservation, let’s say, at the beginning of a new year.
There could be some complexity to manage the cancellation for the different types users. We could use the difference between these types of members to split the story into functionality specific to what each type of member can do. This technique is called splitting based on variations in business rules.
Using this technique, we can split the original story into 2 smaller stories: one story to support cancellations up to the last minute for the monthly members, and the other story to allow the yearly members to cancel only at the end of the year. You may notice that the work required to build the functionality for the first story is different than the one required for the second. By splitting the two stories, we create two smaller stories.
We just used two different techniques to split the original story into smaller ones. The point here is that there are different techniques and we can use them depending on the specific situation. In the rest of the article, we are going to look at some additional techniques.
Why split stories?
There are several reasons to split large stories into smaller ones
To fit into a Sprint
First of all, the smaller stories may fit into a Sprint. Since the bigger story may not be done in a Sprint, we need to split it so that we can deliver a piece of that story by the end of the Sprint. It may not represent the full functionality, but at least we deliver part of it and we can iterate on it in subsequent Sprints.
To accelerate value delivery
We can deliver individual parts of a large story at different times. This allows you to validate a possible solution to the user’s needs before going too far. For example, if we need to build a big functionality, instead of building the whole thing, we could identify some core elements of that functionality and build only these core elements. Then we test with our customers and validate if what we have built so far works for them. If it does, then we can build the rest. If it doesn’t, we stop and reassess our strategy, and maybe we build something different. We are not wasting time in building a full functionality that customers may not use.
As a result you accelerate the delivery of value to your customers.
To estimate more accurately
Another advantage of smaller stories is that the estimates become more accurate. Smaller stories are easier to understand, while large stories may have a lot of complexity or uncertainty. As a consequence, the estimates of larger stories tend to be less accurate than those of smaller stories.
When you have more accurate estimates, the planning becomes more predictable (your Sprint Backlog, your Roadmap, or your Release Plan). Smaller stories help to set more accurate expectations in terms of commitments or release dates.
What to avoid when splitting stories
When we split stories, there are a few things we should avoid. In the end, we want to make sure that each story is valuable, and delivers some functionality. We want to put that in the hands of customers so they can demo it and give us some feedback.
While in real life sometimes we need to compromise, it is useful to keep the following rules in mind when splitting large stories into smaller ones:
Don’t split into very small tasks
We don’t want to split into very small tasks that define the “how”. And we don’t want to split into granular tasks that specify what each team member should work on. That’s not what a story should describe.
The “how” and the small tasks can be identified by the developers if they like to do that. They can do as part of refinement, or they can do this every day at Daily Scrum to decide what to focus on for the day, and who is going to do what. This is their choice if they like to work that way, but for the Product Owner, there is no need to split the stories in this way.
Don’t split by component
Don’t slice a story by components. As an example for a digital application, don’t slice a big story by UI work, database work, and API integration work. Each one of these is a component of what the developers need to work on. If you split by component, you are not going to deliver value to the end user until you have completed all of the components. In the example above, since you have three components, if you tackle one per Sprint, you need to wait 3 Sprints to deliver any value. That just doesn’t work and delays the feedback from the end users.
Instead, make sure that every story delivers value independently. A story should be “vertical”, spanning across all the different components.
That means that when you split a large story, the resulting stories may deliver just a small piece of functionality (whatever you can accomplish in a Sprint), but what you deliver works. The customers can use it and they can provide feedback on it if needed.
Don’t split by person or by team member
We also don’t want to slice stories based on the person that is going to do the work. For example, don’t create a story for the “graphic designer” and another story for the “tester”. These may be sub-tasks that the developers identify on their own. But a story should describe a functionality or a work item that the team is going to execute. Regardless of who is the person on the team that is more specialized in doing the particular work.
Don’t try to make all parts equal
You should not split large stories into smaller stories of equal size. When we go from a big story to smaller stories, not every story needs to be of equal size. There is no need for that.
Don’t try to fit into an arbitrary story point estimate
Sometimes, I hear that a team has created an arbitrary rule so that every story needs to be less than 2 or 3 story points in size. Where does that rule come from? How did the team decide the 2 or 3 point threshold? Often, this is an arbitrary number and I find this rule prone at creating any of the dysfunctions listed above.
The fact is, a story should be small enough to fit into a Sprint. What this means varies by team and by the team’s Velocity, but in general if the story fits into a Sprint, it’s small enough.
For example, if the team has a Velocity of 50 points per Sprint, it can take on several 13-pointers in a Sprint. These stories fit into the Sprint and there is no need to split them further.
On the contrary, if a team has a Velocity of 15 points, then a 13-pointer is too large, and the team may want to split it into a few smaller stories. There is no universal rule, as it depends on the team.
Can a team work on just one story in a Sprint? Yes, that’s possible. The whole team works together on that story, dividing the work among the team members as they see fit. And they deliver that functionality at the end of the Sprint.
In general, though, teams tend to take on several stories in a Sprint.
If you want to establish a threshold for the estimates, instead of imposing an arbitrary number, base it on your team’s Velocity. For example, establish your story point threshold at 25% to 33% of Velocity. As long as a story is smaller than that threshold, you are good. This threshold means that – at a minimum – a team should be able to take on 3 or 4 stories each Sprint.
Sequencing of stories
One final note on splitting stories.
When you take a big story and split it into smaller ones, the resulting stories are (and should be) independent: that is, they can be built one at a time and the system is stable and usable. There could be a sequencing (one story should be built before the second one), but you could build the first story without depending on the second one.
This, of course, requires that stories are vertical.
And this does not imply that the system is released to production after each story: you may want to build the full functionality before releasing it to the end users. Build incrementally, release when ready.
Consequently, it means that when you split a large story into smaller pieces, the smaller stories don’t need to be executed in sequence. In fact, you could build just the first story, test it with end users, and then decide to pivot and build something different. Or you could defer the second part of a larger story to a later time, while in the meantime build other functionalities that are more valuable.
Hence, when you split into smaller stories, each story is a separate PBI in the product backlog, and can therefore be sequenced, scheduled, and prioritized as needed by the Product Owner (accounting for technical dependencies, and for business priorities, as needed).