A few years ago, I was chatting with a senior developer about Robert C. ‘Uncle Bob’ Martin and the Single Responsibility Principle (SRP). It struck me that the principle might not just apply to software design, but could also be a useful way to think about writing agile user stories.
So I’ve been sitting with the question: should user stories follow the Single Responsibility Principle too?
What is the Single Responsibility Principle?
The Single Responsibility Principle is one of Uncle Bob’s SOLID principles. “SOLID is a mnemonic acronym for five design principles to make object-oriented designs more understandable, flexible and maintainable.” (Source: Wikipedia)
The five principles are:
- Single responsibility
- Open–closed
- Liskov substitution
- Interface segregation
- Dependency inversion
Put simply, the single responsibility principle says
A class should have one and only one reason to change, meaning that a class should have only one job.
A class should do one thing and do it well.
A little technical explanation for the non-coders out there: A class is just a building block in code. It’s like a blueprint or a recipe for creating code objects. An object groups together related data and behaviour. For example, a Car class might define that every car has wheels, an engine, a colour and it and can start and stop.
The Single Responsibility Principle says each class (blueprint) should focus on one responsibility. If a class is responsible for multiple, unrelated concerns, then a change in any of those areas could ripple through the same code and break things. That makes software harder to maintain and harder to test. Keeping each class focused on one responsibility makes the system more cohesive and flexible.
The other four principles are outside the scope of this article, but if you are interested in learning more, this article, A solid guide to SOLID principles, is a good place to start.
What is a user story?
In agile, a user story is a short, simple description of a feature told from the perspective of the person who needs it.
The classic format is:
As a [role], I want [capability], so that [benefit].
Stories are supposed to capture value from the user’s perspective. They’re also meant to be small enough to deliver within a sprint (a fixed period of time) and testable with clear acceptance criteria so we know when it is truly done.
Applying SRP thinking to user stories
Let’s put these two ideas together.
Here’s the analogy:
- A class with two reasons to change is too broad.
- A user story with two unrelated outcomes is also too broad.
If you’ve ever read a user story like “As a student I want to register for my courses and receive my timetable so that I can start the semester smoothly”, you’ll recognise the problem. That’s two quite different outcomes bundled into one card.
As one experienced business analyst often pointed out to me: look out for the word ‘and’ in user stories – ‘and’ is often a clue that a user story is trying to do too much.
Refactoring the story
Instead, you could split it into:
As a student, I want to register for my courses so that I can secure my place in the classes I need.
and
As a student, I want to receive my timetable so that I know when and where my classes are.
Both are now clearer, smaller, and easier to estimate and test.
Notice too that the benefit for each is also more specific.
More examples
Online shopping cart
Violates SRP: As a shopper, I want to add items to my basket, calculate shipping, and pay with my credit card so that I can complete my purchase.
Refactored:
- Add items to basket
- See shipping costs
- Pay by card
Employee self-service system
Violates SRP: As an employee, I want to update my personal details and request annual leave so that my records are correct and I can plan holidays.
Refactored:
- Update my personal details
- Request annual leave
The benefits
Thinking about user stories in Single Responsibility Principle terms gives us some real advantages:
- Clarity: each story has one clear purpose.
- Estimability: easier to size accurately.
- Testability: acceptance tests map cleanly to one outcome.
- Traceability: changes in requirements affect only the relevant story.
The risks
But there are risks in taking the analogy too far:
- Over-fragmentation: splitting stories too finely creates backlog clutter and admin overhead.
- Loss of context: if you break a journey into tiny pieces, you risk losing sight of the bigger picture.
- Conversation killer: user stories are meant to be placeholders for conversations, not contracts. Treating the Single Responsibility Principle as dogma could shut down useful dialogue.
Where epics could help
In software, we group classes into modules to give structure. In agile, epics and themes do the same job.
The “Complete online purchase” epic can contain stories like “Add item to basket”, “See shipping costs”, “Pay by card”, and “Receive receipt”. Each story has one reason to change, but the epic ties them together into a coherent user goal.
And we only need to break them out of the epic when we’re about to work on them. That way, they keep their context for longer which helps with discussions about them and they don’t get lost in a sea of user stories.
So, should we?
I think the Single Responsibility Principle offers a helpful lens for writing user stories – not as a hard rule, but as a heuristic.
By heuristic I mean a rule of thumb – a guide that helps you make better decisions, not something to apply dogmatically. It’s a way of noticing when a story might be trying to do too much, and a reminder to ask, “Could we make this clearer or smaller?”
If a story has multiple unrelated outcomes, that’s a smell. Splitting it usually improves clarity and flow. But if two outcomes only make sense together, or splitting them would create noise without value, then keep them together.
Like most things in agile, it’s about balance. Use the Single Responsibility Principle to sharpen your instincts, not to replace good judgement and conversation.
What do you think?
Have you tried writing user stories with the Single Responsibility Principle in mind? Did it help, or did it just add noise? I’d love to hear your thoughts.
Photo by Tom Parsons on Unsplash
