← Back to Week 3 Hub
User Story Anatomy
A user story describes a feature from the perspective of the person who'll use it. Three parts — role, action, benefit — and one important rule.
Every user story answers: who wants it, what they want, and why. The "why" is what separates a real user story from a random task. Without it, you don't know if the feature is worth building.
The template
As a [role], I want [action], so that [benefit].
[role]
The real user of the product — the person who will actually benefit from this feature.
customer · admin · store owner · guest · cashier · student · patient
[action]
What the user wants to do in the product. An action they can take.
search for a product · filter the list · add to cart · reset my password
[benefit]
The outcome or value. Why this action matters to the user.
so I can find what I'm looking for · so I can buy without logging in first
Good user stories
As a customer, I want to search for a product by name, so that I can find what I'm looking for without scrolling through everything.
As a store owner, I want to add new products to the catalog, so that I can keep the inventory up to date.
As an admin, I want to see a list of all orders, so that I can track what's been sold.
All written from the real user's perspective — a customer, a store owner, an admin. Each one has a clear "so that" — the why.
Bad "user stories"
As a developer, I want to create the base project structure, so that the team can start coding.
Add login form.
As a user, I want the site to be fast.
The first has the wrong role (a developer isn't a user). The second is missing the "as a…" and "so that…". The third is too vague — "a user" who? fast how?
⚠ The "As a developer" anti-pattern
You'll sometimes see sample user stories that look like this:
"As a developer, I want to create the base project structure, so that the team can start coding."
This isn't a user story — it's a technical task dressed up in the user-story template. User stories describe value for a real end user (customer, admin, store owner, etc.). Setting up the repo, adding a linter, creating folders — those are technical tasks that live on the same project board, but they shouldn't use the story template.
Don't write it like this
"As a developer, I want to create the base project structure, so the team can start coding."
Confusing — pretends to be a user story but describes setup work.
Write it like this
Task: Create base project structure
Plain task description. Add a checklist of steps. Goes on the board as a technical task, not a user story.
Tip: when in doubt, ask — "who benefits from this, and what do they want to do?" If the answer is "a developer, so we can build stuff," it's a task, not a story.