Sometimes it’s hard to break down a user story into smaller parts.
There’s a piece of work, and it seems that it all needs to be done together, but it’s much too large to fit into a single sprint, so what do we do?
Horizontal vs Vertical
It’s often tempting to slice a story horizontally. That’s what many engineers would do. They would slice the story based on the different elements of the technology stack.
We would end up with separate stories for the user interface, API business logic, database, and maybe even a separate story for testing.
The problem with this way of slicing up work horizontally is that we can’t deliver any value to the customer until all of the stories are complete. If we develop just the user interface, but haven’t done the rest, then there’s nothing to deliver to the customer.
So how can we do things better? Well, that’s by slicing stories vertically.
A vertical slice delivers a small piece of functionality required across all the layers of the tech stack. It will include changes to the UI, API and Database, and be fully tested.
The benefit of slicing stories this way is that each story can deliver some working demo-able value to the customer. The functionality in each story works on its own, and so it removes dependencies on other stories.
Ways of splitting stories
Thanks to the good people at Humanizing Work, we have this amazing flow chart that can help us break down stories:
We can split stories in a number of ways:
- Workflow steps – split a story based on the different variations of the process. If your process has variations, then you can have each variation as its own story.
- Operations – split a story based on the different actions or operations that can be done to an object. Instead of ‘managing’ a user record, we can have stories to ‘add’, ‘update’, or ‘delete’ a user record.
- Business rule variations – split a story based on the different rules that apply for different roles or circumstances. A sales manager may have different rules when recording a sale to a sales assistant.
- Variations in data – split a story based on the different values. There may be a different process to follow if the ‘manager’ field is true or false.
- Major effort – split a story into several parts where the first story might do the heavy lifting of creating functionality, and the other stories are smaller effort to create variations of the first.
- Simple/complex – split a story to deal with the happy path, or simple version first, and then have other stories for the more complex journeys.
- Defer performance – split a story to make the feature work (albeit slowly), and then have other stories to improve performance.
- Break out a spike – when the technology is not well understood, take some time to investigate first before trying to build anything.