← Back to Week 3 Hub
Workbook 3b — Exercise
User Stories — Hardware Store
Convert feature requirements into user stories written from a real user's point of view | Workbook p.20
The Exercise
You've been handed a list of eight requirements for a Hardware Store application. Your job is to rewrite each one as a user story — a short sentence written from the point of view of the person who actually benefits from the feature.
Every story must come from a real user of the system: a customer, a store owner, a cashier, an admin, a guest. Ask yourself: who actually uses this feature, and what do they get out of it? Some requirements will produce more than one story — the same feature might matter to a customer and a store owner in different ways.
- A customer should be able to search for a product.
- A customer should be able to filter the products list.
- A customer must be logged in to make a purchase.
- A store owner should be able to add new products.
- A store owner should be able to see a list of orders.
- We should be able to remove a product.
- We need to update product inventory.
- We need to print an Order Pick List for each order in the store warehouse.
The Template
As a <role>,
I want <action>,
so that <benefit>.
role = who
action = what
benefit = why
Example — Two Model Answers
Requirement 1 — customer search
As a customer, I want to search for a product by name, so that I can find what I need quickly.
Requirement 4 — store owner adds product
As a store owner, I want to add new products to the catalog, so that I can keep the inventory up to date.
Two done, six to go. For the rest, think about who the real user is first — then figure out what they want, and why they'd want it.
Watch Out — Anti-Patterns
Don't write "As a developer, I want to..." — that's a technical task, not a user story. Setup work like creating a project or wiring up a database doesn't belong in the As-a / I-want / so-that template.
As a developer, I want to create the base project structure, so that I can start coding.
That's a technical task. Write it as a plain to-do item on the board instead.
Don't write vague stories like "As a user, I want the app to be fast."
As a user, I want the app to be fast, so that it feels good.
"User" is too generic, "fast" isn't measurable, and "feels good" isn't a real benefit. Name the role, name the action, name the payoff.
Tips
- Think about who actually uses this feature before you write anything — customer, store owner, cashier, admin.
- Think about their goal — what are they trying to accomplish in the real world?
- Every story has a "so that..." — if you can't say why it matters, the story isn't done.
- One requirement may produce multiple stories for different user types (e.g. "remove a product" matters to a store owner and affects what a customer sees).
- Keep each story to one sentence. If you need more detail, that's what the acceptance criteria are for.
Workbook 3b, p.20 — Exercise: Hardware Store User Stories