Why we split user stories
Before we can start talking about why we split user stories, we probably need to discuss exactly what a user story is.
Most people involved with software development will recognise a user story as looking something like this:
As a [blank], I want to [blank], so I can [blank]
The first [blank] represents the type of user the feature is for, the second [blank] describes some action they want to perform, and the third [blank] is an explanation of why they want to perform that action.
For example, if we wanted to build a feature which allows the addition of items to a basket within an ecommerce system, we might write something like:
As a customer, I want to add an item to my basket, so I can purchase it
Historically, this structure was used because it was short and to the point, meaning it could be written on a physical index card and placed in a Kanban board, allowing it to be easily identified as it progressed through to completion.
And for many developers, sadly, that’s as much information they’ll ever get. I mean, they know what needs to be done, don’t they? For whom, and for why? What else could they possibly need?[1]
What do I Need in my User Story?
But the truth is, a “user story” as defined above, is still missing a lot of information, for example:
- What action does the customer perform to add something to the basket?
- Are there any side effects of adding to the basket?
- What happens if the item is out of stock?
- How should variations, such as size or colour, be handled?
- What happens if they already have the same item in the basket?
And it’s the answers to these questions which make up the bulk of the story, serving as acceptance criteria to identify when a feature is complete and giving the development team full context, letting them truly understand the requirements of a new feature.
Importantly, the development team are not being told how to solve the problem – they’re the ones with the technical know-how and are best placed to make that decision – they’re just being given the relevant information needed to solve the problem, and importantly, how to know when they’ve done that.
Unfortunately, the answers to these questions can be (and often are) large enough in scope that they need their own user story.
Let’s look at the out-of-stock question, for example. In this instance the client doesn’t want to lose any potential sales, so has asked for a customer notification system for when items are restocked. This needs a way of capturing the customer’s email address, a system which recognises that a previously out of stock item is now back in stock, and a mailer addressed to the customer informing them.
But what does any of this have to do with adding an item to the basket?
It’s tangentially related for sure, but even if it’s an important requirement, that’s not a good enough reason to let it hold up the delivery of the rest of the feature. After all, if no one can add items to their basket, the client is going to be losing 100% of sales, not just the out-of-stock ones.
By splitting the story we’re providing several benefits:
- Letting the development team focus on one problem at a time.
- Releasing features more quickly.
- More focused testing and quality assurance.
- Not having acceptance criteria which (at that point in time) are impossible to deliver.
- Having less chance of important nuance being missed among the noise.
But I’m saving my best benefit until last, which I’ll explain via a true story.
A True Story: Splitting the User Story
Among the various features requested by one of our clients during the rebuild of an educational platform they provided, was the requirement for a token-based payment system. The idea was that schools would purchase tokens in bulk and spend them each time they used the platform.
Early in the discovery phase there was a fair amount of discussion about tokens in relation to other features, such as displaying the number of tokens remaining, warnings about unused tokens when attempting to delete records, and specifics on how they were consumed by the app.
Our roadmap had token implementation planned for around the fifth sprint, so each time a story which mentioned tokens was picked up prior to this, we’d go in and split the token-specific acceptance criteria into their own story.
I’ll be the first to admit, this confused the client – the token concept was literally how they were going to make their money, after all – but we explained the benefits of preventing this unrealised concept getting in the way of delivering other features and made sure to show that we weren’t saying “no” to these details, just “not now”.
Fast-forward towards the end of the fourth sprint, and we got a message from the client that they were scrapping the token system, replacing it with a subscription-based solution which allowed unlimited use of the tool during the subscription period.
This was unexpected, but because we had split specifics related to tokens into their own stories, no time had been spent building features which were suddenly no longer relevant. And this is one of the more common benefits to splitting stories: the ability to quickly adapt to changes in the market.
At the end of the day, user stories are a tool like any other, and when used properly can be a powerful aid to getting the right work done, at the right time.
[1] And to be fair, this is an improvement on some feature requests I’ve had in the past, consisting of nothing more than a vague train of thought presented on a scrap of paper, without any further clarification.