User story examples: 16 annotated stories, good and bad

Sixteen user story examples across auth, e-commerce, mobile, APIs and bugs — each annotated, with the bad versions shown next to their rewrites so the difference is visible.

Sixteen user story examples, drawn from the domains teams actually work in: authentication, e-commerce, mobile, APIs, bugs, and internal tools. Each one is annotated — not just what the story says, but why the role and benefit clauses earn their keep. Four are deliberately bad, shown next to their rewrites, because the fastest way to learn the format is to watch it fail.

If the format itself is new to you, start with what is a user story? — the short version is that every story here follows “As a [role], I want [goal], so that [benefit]”, and every good one could go straight into refinement and a round of planning poker.

Authentication and accounts

1. Sign-in

As a returning customer, I want to sign in with my email and password, so that I can see my order history.

Why it works: the role is specific. “Returning customer” tells you this person has an account, has ordered before, and has a reason to come back — three facts a designer and a tester can use. “As a user” would have carried none of them.

2. Password reset

As a locked-out user, I want to reset my password from the sign-in screen, so that I can get back into my account without contacting support.

Why it works: the benefit clause names a real cost. Every reset that goes through support is measurable money, so this story can be prioritized against others on evidence rather than vibes. Note what the sentence doesn’t carry — token expiry, rate limits, the email template. That detail belongs in the acceptance criteria, written when the team refines it:

  • A reset email arrives within two minutes of the request.
  • The reset link expires after one hour and can be used once.
  • The form gives the same response whether or not the email exists (no account enumeration).

3. The circular story

As a user, I want to log in, so that I can access the app.

Why it fails: every slot is filled and nothing is said. The role is nobody in particular, and the benefit restates the goal, so the “so that” clause could be deleted without losing information. A story like this passes the format check while skipping all the thinking the format exists to force.

The rewrite:

As a project member returning mid-sprint, I want to land on the board I last viewed after signing in, so that I don’t re-navigate there every morning.

Now there’s a person, a moment, and a benefit someone could weigh against other work.

E-commerce

4. Cart persistence

As a shopper browsing on my lunch break, I want my cart to keep its items when I come back tonight, so that I don’t have to find everything again.

Why it works: the role carries a scenario. “Browsing on my lunch break” explains why carts get abandoned mid-flow, which tells the team the persistence window that matters is hours, not seconds. A well-chosen role smuggles context into one clause.

5. Guest checkout

As a first-time buyer, I want to check out without creating an account, so that I can finish my purchase before I change my mind.

Why it works: it takes a product position (accounts are optional) and states the honest benefit — hesitation kills first purchases. Stories this clear also expose disagreement early: if the business wants every buyer to have an account, that fight happens in refinement, not in the pull request.

6. The metric wearing a story costume

As a shopper, I want a faster, cleaner checkout, so that conversion improves.

Why it fails: twice over. “Faster, cleaner” isn’t a capability anyone can build or test, and “conversion improves” is the business’s benefit, not the shopper’s — no shopper wants conversion. This is a quarter’s worth of work compressed into a sentence, which makes it an epic, not a story.

The rewrite (one slice of it):

As a buyer on my phone, I want my shipping address autofilled from my postcode, so that I can complete checkout one-handed.

The epic becomes a backlog of slices like this, each one testable and small enough to size.

Mobile

7. Offline mode

As a field technician, I want today’s job sheet to load without a connection, so that I can keep working in basements and dead zones.

Why it works: the role selects the requirement. Office staff never notice offline support; field technicians live in it. When someone asks “how offline is offline?” in refinement, the role has already answered — wherever the job takes them.

8. Notification preferences

As a subscriber getting three pushes a day, I want to choose which alert types send notifications, so that I stop muting the whole app.

Why it works: the benefit names the failure mode the story prevents. Users don’t complain about notification volume; they mute the app and quietly leave. A story that names the silent behaviour it’s defending against is a story the team can argue about honestly.

APIs and technical work

9. Pagination

As an integration developer, I want paginated responses on the /events endpoint, so that my nightly sync doesn’t time out on large accounts.

Why it works: this is the legitimate technical user story — the developer is a real, external user with their own goals, not the team writing itself into the sentence. API consumers, plugin authors, and on-call operators all pass that test.

10. Rate limiting

As an API consumer, I want a 429 response with a Retry-After header when I hit the rate limit, so that my client can back off instead of failing the whole job.

Why it works: the goal is precise enough to be its own first acceptance criterion, and it’s still a what, not a how — nothing here dictates the limiter’s implementation.

11. The refactor in disguise

As a developer, I want to refactor the payments module, so that the code is cleaner.

Why it fails: the role is the team, the goal is an activity rather than an outcome, and “cleaner” can’t be tested. This is the story format applied to work it wasn’t designed for — a case covered in when user stories are the wrong tool.

The rewrite (not a user story, on purpose):

Reduce the payments module’s provider-coupling so a new payment provider can be added without touching core checkout. Done when: the provider interface is extracted, the two existing providers run behind it, and the integration test suite passes unchanged.

A plain technical item with a named outcome beats a costumed story every time.

Bug or story?

12. The bug that is a story

As a customer on an annual plan, I want my invoice to show the discount I was quoted, so that finance can reconcile it without a support ticket.

Why it works: the cause is known and the fix has clear scope, so this behaves like any other story — it gets criteria, a size, and a slot in the sprint. Pointing bug work keeps velocity honest about where capacity actually goes; the story points chapter makes that argument in full.

13. The bug that isn’t

Customers intermittently report being charged twice. No reliable reproduction.

Why it’s not a story: there is no scope to promise. A role-goal-benefit sentence (“As a customer, I want to not be charged twice…”) would be true and useless, and any estimate would measure hope. The right move is a time-boxed spike: investigate for two days, deliver what was learned, then write the real story for the fix.

Internal tools and reporting

14. Support tooling

As a support agent on a live chat, I want to see the customer’s last five sign-in attempts, so that I can tell a forgotten password from a locked account in one look.

Why it works: internal users are still users. The benefit is measured in seconds-per-ticket, which is exactly the kind of concrete stake that lets this story compete with customer-facing work for a sprint slot instead of losing by default.

15. Exports

As a team lead, I want to export the sprint report as CSV, so that I can share results with stakeholders who don’t have accounts.

Why it works: the “so that” clause quietly scopes the work. Sharing outside the tool is the job, which rules out solutions like in-app dashboards and rules in boring, portable CSV. A good benefit clause does design work for free.

16. The visibility epic

As a manager, I want a dashboard of everything the team is doing, so that I have visibility.

Why it fails: “everything” is not a scope and “visibility” is not an outcome — nothing here can be built, tested, or sized. Underneath a story like this is a real question the manager hasn’t been asked yet.

The rewrite:

As a delivery manager preparing the Monday status call, I want each team’s sprint goal and its red/amber/green state on one page, so that I can flag blocked work without pinging every lead.

Same person, same instinct, but now it fits a sprint and a tester knows when it’s done.

What the good ones share

Look back across the twelve that work. Each names a person specific enough to have an opinion, states a goal that person would recognize, and carries a benefit that survives one honest “why?”. None of them contain implementation, and none of them try to be complete — that’s what acceptance criteria and the refinement conversation are for.

The bad four fail in exactly two ways, which is encouraging: either the benefit is circular (nobody checked why) or the scope is an epic (nobody checked how big). Both failures surface the moment your team tries to estimate the story, which is why sizing sessions catch bad stories faster than any writing guideline — a wide vote spread is the format’s error message. Write your next batch against the template, then put them in front of the team with planning poker and see which ones converge.

Frequently asked questions

What is an example of a user story?

“As a returning customer, I want to sign in with my email and password, so that I can see my order history.” It names a specific person, a capability in that person’s terms, and the reason the work is worth scheduling. That three-part shape (role, goal, benefit) is the classic user story format.

How do you write a good user story?

Name a specific role rather than “a user”, state the goal as something the person does rather than something the system contains, and finish the “so that” clause with a benefit that would survive one honest “why?”. Then attach acceptance criteria, because the story sentence is a conversation starter, not the requirement.

Can technical work be written as a user story?

Sometimes. If the “user” is real — an integration developer consuming your API, an operator on call — the format works as written. If the only honest role is “the team”, drop the costume and write a plain technical item with a named outcome and acceptance criteria. The discipline transfers; the sentence shape doesn’t have to.

Should bugs be written as user stories?

A bug with a known cause and a clear fix can be, and pointing it keeps velocity honest. A bug nobody can reproduce cannot: there is no scope to promise, so a story would just be a guess with a benefit clause. Time-box an investigation first, then write the real story for whatever it finds.

How detailed should a user story be?

One sentence of story, then three to five acceptance criteria. The sentence earns the conversation; the criteria capture what the conversation decided. If the criteria list keeps growing past five, the story is several stories, and the criteria are showing you where to split it.