Reading and writing software documentation rarely make it onto the list of the most exciting daily tasks.
Technical documentation, almost by nature, tends to be rather rigid — full of jargon, specific terms, and structures that don’t always connect with the people who are actually going to use the system. Ironically, all this formality is supposed to bring clarity and flow to the process — which, in my experience, is far from reality.
At the opposite end of the spectrum, a curious movement emerged.
A group of people — who knows why — interpreted the Agile value “individuals and interactions over processes and tools” to mean something like: “documentation is irrelevant, let’s fire the requirements analysts.”
To this day, I don’t quite understand where that interpretation came from… but it gained traction in some parts of the world.
And so, between the excessive rigidity of traditional documentation and the “anything goes” of anti-documentation thinking, User Stories emerged: a lighter, more accessible, and functional way of recording requirements — without sacrificing understanding, clarity, or, most importantly, value for the end user.
1. Where Did User Stories Come From?
The idea originated back in the early days of agile methodologies, with Extreme Programming (XP) — which you might know as one of the pioneers of the agile movement, though that story has been told elsewhere far more eloquently than I could tell it. So I’ll stick to the practical side of things.
At the time, the proposal was simple and powerful:
Instead of having only analysts define what would be built, clients themselves would describe what they needed through short, straightforward stories. Something like:
“Users define the scope using stories that represent what they want to do in the system — similar to use cases.”
Over time, User Stories evolved.
They gained structure, purpose, and moved away from the formalism of use cases, becoming one of the pillars of documentation in agile projects.
2. So, What Is a User Story?
A User Story is a requirements artifact — just like a use case — but with one key difference: it is simple, informal, and user-centered.
Another important point, especially in our context:
While a use case focuses on system behavior (what it does, how it reacts, what happens at each step), the user story focuses on the user, their intent, the action they want to perform, and the value they expect to gain as a result.
What about the system’s internal behavior? It matters, of course. But only up to a point.
A user story doesn’t concern itself with what happens “behind the scenes” — it focuses on what really matters to the user: the practical outcome.
In short, while the use case asks “How should the system behave?”, the user story asks “What does the user want to do — and why does it matter to them?”
3. How to Write a User Story?
There are several ways to write one, but they all follow roughly the same logic.
Here are some common models:
- Classic model (Connextra, 2001):
“As a <role>, I want <goal> so that <benefit>.” - Mike Cohn (simplified version):
“As a <role>, I want <goal>.” - Chris Matts (functionality-driven):
“In order to <benefit>, as a <role>, I want <goal>.” - Five Ws model (who/when/where/what/why):
“As <who>, <when>, <where>, I <what>, because <why>.”
However, the most commonly used format these days is:
“As a [role], I want [action/goal], so that [benefit].”
Or a slight variation:
“I, as a [role], want to [action], so that [benefit].”
In the end, the exact model doesn’t matter much.
What matters is that it makes sense to the team, is clear and understandable, and strongly conveys the user’s need.
The focus should ALWAYS be on clarity and communication — and that’s precisely the difference between meaningful collaboration and bureaucratic rule-following.
4. A Quick Example (With a Sporty Touch)
As a salesperson
I want to register a customer
So that I can include them in the loyalty program
Let’s break that down:
- Actor: salesperson
- Goal: register a customer
- Expected benefit: include them in the loyalty program
See how the story is extremely simple and direct?
It presents a real, everyday action with a clear and well-defined purpose.
And most importantly: anyone on the team — technical or not — can understand it.
In this example, the “so that” part could technically be optional.
But here, I think it’s worth including, because the value of the action isn’t immediately obvious — and that detail matters.
Saying just “I want to register a customer” might raise questions: for what? What’s the goal?
Adding “so that I can include them in the loyalty program” closes the loop with clarity.
Now, if the benefit is already implied in the action, you can safely leave it out — no guilt necessary.
After all, the goal isn’t to be rigid. It might look like this:
As a salesperson
I want to register a customer so they can be added to the loyalty program
The key is not following the template to the letter, but ensuring that the story clearly communicates what the user wants to do and why it matters.
Done. A simple, clear, complete story.
Here, we:
- Identified who the actor is (salesperson)
- Understood what they want to do (register a customer)
- And why (to include them in the loyalty program)
All in a sentence anyone can understand — even someone who’s never written a single line of code.
To Wrap Up…
User Stories are a super effective way to bring the development team closer to the real world of the users.
They help pull requirements out of the abstract in a light, fast, and value-focused way — centered on the people who’ll actually use the product.
So, next time someone suggests starting a project with long, formal use cases… maybe it’s worth asking:
“What if we started with a good story instead?”
Let me know if you’d like this in a formatted PDF, visual guide, or adapted to a specific audience (e.g. for product managers, developers, or clients).