How to split large user stories into smaller ones

I’ve already defined user stories and talked about how useful they are for encapsulating the features of a product in a way that makes value apparent. I also mentioned that when we have stories that are too large to fit into a single sprint they need to be split up into smaller user stories. So how do we do this?

What makes a good user story?

Bill Wake’s INVEST mnemonic reminds us of the characteristics of a good user story (Independent, Negotiable, Valuable, Estimable, Scalable and Testable). It builds on Kent Beck’s assertion that a story that is ready to create a product increment from is “…understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration.”

Stories that are too large dominate a sprint, making it hard to assess progress. They are more difficult to understand and estimate. They keep specialists in the team (e.g. testers) waiting around for days. They can also allow unnecessary features to creep through a sprint by reducing the amount of scrutiny to which stories are subjected. All of the above obviously reduce the amount of value that your team is generating.

Luckily it is almost always possible to vertically slice through large user stories to produce smaller, more manageable stories that help your team to work more effectively.

Why slice vertically?

First of all, what do I mean by slicing vertically? When splitting up user stories you generally have two options. The first is to take a horizontal slice, separating the user story into different components grouped by the type of work that needs to be done e.g. all the UI tasks as one story, all the back-end tasks as another story, all the testing as another story.

This is very un-Agile. First of all you’re silo-ing your team up into their respective specialisms rather than leveraging the benefits of collaboration. Doubtless bottlenecks will arise and you’ll have some team members hanging around waiting for others to finish a story before they can start theirs. Secondly, none of the stories will generate any value in and of themselves since none, by themselves, provide a tangible benefit to the user. Lastly, not only is it impossible for a Product Owner to prioritise a story that has no value, if the story is also very technical (by virtue of being composed of a single area of expertise) then it will be hard for the PO and other team members to grasp.

The other, much more preferable option, is to slice vertically through a user story so that each resultant smaller story provides value to the user and is testable.

This might sound like an impossible ask but there are a number of ways of looking at user stories and splitting them into tidy vertical slices. Let’s take a look at some of those methods.

Approaches for slicing user stories

There are a number of aspects from which the complexity of a user story might arise, each of which might lend itself to taking a vertical slice through the story:

Sometimes a little extra creative thinking is required but the above approaches should enable you to split the vast majority of large user stories.

Worked example – a list of credit card transactions

Here’s an example user story for a credit card app:

“As an authenticated user I want to view a list of transactions”

And some acceptance criteria:

1. Must be able to see all transactions
2. Must be able to see date, amount, recipient for each transaction
3. Must be able to order transactions by date, amount

We’ve agreed that this user story is too large to fit comfortably into a sprint so how do we break it down into more manageable stories?

One option is to take each acceptance criteria and provide a number of alternative options from the simplest to the most complex e.g.

Then we pick a set of criteria that is rich enough to deliver an initial story but which leaves extra richness that can be delivered by subsequent stories.

So we have a new initial story which might be:

“As an authenticated user I want to view a list of recent transactions”

With the acceptance criteria:

1. Must be able to see last 10 transactions
2. Must be able to see the date and the amount for each transaction

This new story meets the INVEST criteria. With it we’re also delivering a large chunk of the value that was encapsulated in the original story but, because we’ve been able to simplify and slice vertically, we’re now in a position to deliver something at the end of the sprint that is potentially shippable.

Conclusion

You may receive some resistance from teams new to user stories and Scrum when starting to slice stories in this way. Comments like ‘it’s easy to just add an extra field’ or ‘why don’t we do it all now to save time’ are not uncommon. Good story slicing and understanding how and why you’re doing what you’re doing gets to the very core of Agile – the art of what you don’t do in order to maximise value delivered.

Thanks to Matt Roadnight for help with the material in this blog post.