How do you write user stories and acceptance criteria?

Direct answer

What a strong answer covers

How it works

A story is a placeholder for a conversation: it names who wants something, what they want, and why, so the team can judge value and think of alternatives. The acceptance criteria are where the conversation lands: concrete rules, example inputs and outputs, who is allowed to do it, what happens on error, and what is out of scope. Good criteria are readable by the stakeholder and executable by the tester without further clarification, and they describe outcomes rather than the buttons or tables used to reach them. A story that cannot be delivered and demonstrated within a sprint is split by outcome, not by layer.

Example

As a finance manager, I want to export approved invoices for a date range so I can reconcile with the bank. Criteria: only invoices in status approved within the inclusive range are included; the file has one row per invoice with number, date, customer, net, tax, total in the account currency; a range with no invoices produces an empty file with headers; users without the finance role receive a permission message and no file; exports over 10,000 rows run in the background and email a link.

Common mistakes

• Writing the story as a task such as add an export button.
• Leaving criteria as the feature should work correctly.
• Splitting a story into database, API, and UI pieces that each deliver nothing usable.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.