User Story Examples, With Acceptance Criteria

Good user story examples share three things: a specific person, something they can do or see, and a reason that tells the team when they have solved the problem. Each of the twenty below is followed by two to four acceptance criteria, written as a checklist of statements that are either true or false. They are grouped by the kind of product, so you can take the nearest one and change the nouns.

The format itself, INVEST and a blank card to copy are in the user story template. The criteria here are checklist style; the Given/When/Then↗ (opens in a new tab) style, and when to use which, is in acceptance criteria examples.

E-commerce

1. As a returning customer, I want to reorder a past order in one tap, so that my weekly shop takes under a minute.

• Reorder adds every item still on sale to the cart at the original quantity.
• Items no longer sold are named in a message, not silently dropped.
• Prices shown are today’s prices, not the old order’s.

2. As a shopper comparing delivery options, I want to see the delivery date before I enter my card, so that I only pay if it arrives in time.

• Every delivery option on the basket page shows an expected date.
• Changing the postcode updates the dates without reloading the page.
• An address outside the delivery area says so before the payment step.

3. As a customer who received a damaged item, I want to start a return from my order page, so that I do not have to email support.

• Each item delivered in the last 30 days has a Return button.
• The form asks for a reason and allows up to three photos.
• Submitting sends a confirmation email with a return reference.
• Items outside the return window show why the button is missing.

4. As a store manager, I want to be told when a product drops below five in stock, so that I can reorder before it sells out.

• An email is sent once when stock falls from five or more to below five.
• No second email is sent until stock has gone back above five.
• The threshold can be changed per product.

SaaS admin

5. As an account owner, I want to invite a colleague by email, so that they can use our account without sharing my login.

• The invite email contains a link that works once and expires after seven days.
• Inviting an address that is already a member shows a message instead of sending.
• The invited person appears as Pending until they accept.

6. As an account owner, I want to remove someone who has left the company, so that they lose access straight away.

• After removal, that person’s next request is refused, even in a tab left open.
• Everything they created stays, still showing their name.
• The removal is recorded with who did it and when.

7. As a finance lead, I want to download every invoice for a year as one file, so that I can hand it to the accountant in one go.

• The download contains one PDF per invoice for the chosen year.
• File names start with the invoice date so they sort in order.
• A year with no invoices shows a message instead of an empty file.

8. As an admin on a paid plan, I want to see how many seats are used, so that I know before I hit the limit.

• The billing page shows seats used and seats available.
• Pending invites count as used seats, and the page says so.

Mobile app

9. As a commuter with a patchy signal, I want to read saved articles offline, so that the train tunnel does not stop me.

• Articles saved while online open in flight mode, with images.
• An article that has not finished downloading is marked as such.
• Removing an article frees its storage.

10. As a user who signs in rarely, I want to sign in with my fingerprint or face, so that I do not have to remember a password.

• The option is offered only on devices that support it.
• Three failed attempts fall back to the password.
• Turning it off in settings takes effect on the next launch.

11. As a parent using the app one-handed, I want the main action button within thumb reach, so that I can use it while holding a child.

• The primary button sits in the bottom third of the screen on every main screen.
• Its tap target is at least 44 by 44 points.

12. As a user who turned notifications off, I want the app to explain what I am missing before asking again, so that I can decide properly.

• The explanation screen appears at most once a month.
• Choosing “Not now” never opens the system prompt.
• Choosing “Turn on” opens the system prompt or the settings page, whichever the device requires.

Internal tool

13. As a support agent, I want to see a customer’s last five orders beside their ticket, so that I can answer without switching screens.

• The ticket view lists up to five orders, newest first, with status and date.
• Each order links to its full record.
• A customer with no orders shows “No orders” rather than an empty box.

14. As a warehouse picker, I want the pick list sorted by aisle, so that I walk the warehouse once per order.

• Items are sorted by aisle, then shelf.
• Items with no aisle recorded appear at the end, flagged.
• The printed list matches the on-screen order.

15. As an HR coordinator, I want a starter’s accounts requested from one form, so that nothing is forgotten on their first day.

• Submitting the form creates one request per system ticked.
• The coordinator sees each request’s status on one page.
• The form cannot be submitted without a start date.

API

The “user” of an API is a developer or another system. The story still works as long as the reason is about their outcome, not your implementation.

16. As a developer integrating with our API, I want a clear error when my token has expired, so that my code can refresh it instead of failing.

• An expired token gets a 401 with an error code that says expired, distinct from an invalid token.
• The response body says when the token expired.
• Existing error codes are unchanged.

17. As a partner syncing orders nightly, I want to fetch only orders changed since my last sync, so that the job finishes in minutes, not hours.

• GET /orders accepts a changedSince timestamp.
• Results are paged, at most 500 per page, with a link to the next page.
• An order changed twice appears once, in its latest state.

18. As a developer retrying after a timeout, I want repeating a payment request to be safe, so that a customer is never charged twice.

• Two requests with the same idempotency key create one payment.
• The second request returns the first request’s result.
• Reusing a key with a different amount is refused.

Not software: a kitchen refit

Stories work anywhere there is someone to serve. The GOV.UK Service Manual’s guide to writing user stories↗ (opens in a new tab) uses a public-service example, “as a UK resident, I want to get my details on the electoral register so that I can vote”, with criteria written as “it’s done when…”. Here are two from a building job.

19. As the homeowner, I want to choose the worktop from three samples in the kitchen itself, so that I see it in the real light.

• Three samples are left in the kitchen for at least two days.
• The choice is recorded in writing before the worktop is ordered.
• The fitter confirms the order reference to the homeowner.

20. As the site manager, I want every snag photographed before and after it is fixed, so that the client signs off without a second visit.

• Each snag has a before photo when it is logged.
• It is marked fixed only with an after photo from the same angle.
• The client receives the list with both photos for every item.

Five weak stories, rewritten

The Agile Alliance glossary notes that a user story↗ (opens in a new tab) is not a document so much as the knowledge needed to make the product more valuable. Weak stories usually fail because they skip the part that carries that knowledge: the who or the why. Each rewrite below fixes one common fault.

1. No real user. Weak: “As a user, I want a dashboard, so that I can see data.” Good: “As a shop owner, I want today’s sales and yesterday’s beside each other when I open the app, so that I know by 9am whether to run a promotion.” Criteria: both totals appear on first load; figures match the sales report to the penny.
2. The why repeats the what. Weak: “As an admin, I want to export users, so that I can export users.” Good: “As an admin, I want to export the member list, so that I can check it against payroll each quarter.” Criteria: the export includes name, email, role and date added; removed members are not included.
3. An implementation, not a need. Weak: “As a developer, I want a Redis cache on the product endpoint.” Good: “As a shopper on a slow connection, I want product pages to load quickly, so that I do not give up.” Criteria: product pages load in under two seconds on the agreed test connection; prices shown are never more than a minute old. The cache may be how it is done; that goes in the plan.
4. Too big. Weak: “As a customer, I want to manage my account.” It fails the Small in INVEST↗ (opens in a new tab). Good: split it. “As a customer, I want to change my delivery address, so that my next order goes to my new home.” Criteria: the new address is used for orders placed after the change; orders already dispatched are unaffected. Password, email and payment details are separate stories.
5. Untestable words. Weak: “As a user, I want search to be fast and intuitive.” Good: “As a customer who knows the product name, I want search to find it even with a typo, so that I do not browse category pages.” Criteria: “blutooth speaker” returns the Bluetooth speaker first; results appear within one second; an empty result suggests the closest match.

Notice that the third rewrite moves the technical idea out of the story, not out of the work. The cache may still be the right answer; it simply belongs in how the work will be done, where the people doing it can change their minds.

When an AI assistant picks up the story

Any of the twenty can be handed to an AI assistant, but it will not ask the questions a colleague would. Add where the work is, what it must not touch, what evidence to paste, and what to do if it gets stuck. How to write a task for an AI agent covers those additions; the criteria above are already in the form it needs, because each one is true or false.

On fenbs, a story is a task of kind feature or enhancement, and the story sentence with its criteria goes in the task’s Problem box (note over MCP). The approach goes in the Plan box (plan), so the rewrite that moved “Redis cache” out of the story has an obvious place to put it. When the work is checked, the Testing field records Tested, Partly tested, Failed or Needs owner check, with notes on what was and was not checked, and a person moves the task to Completed. There are no sprints, story points or due dates; priority from 1 to 10 and a rough size from XS to XL are as far as it goes.