How to write user stories with acceptance criteria

The user story is the smallest useful unit of product requirement, and the format is deceptively simple: As a [type of user], I want [some goal], so that [some benefit]. The simplicity hides where teams go wrong.

The 'so that' carries the weight

Most people nail "as a" and "I want" and then fumble or skip "so that." That's backwards — the benefit clause is the most important part, because it captures why, and the why is what lets engineering make good trade-offs and lets you spot stories that don't actually serve a user. "As a user I want a CSV export so that I can analyze my data in my own spreadsheet" tells a developer something a bare "add CSV export" doesn't: the export needs to be analysis-friendly, not just technically present.

Acceptance criteria define done

A story says what; acceptance criteria say when it's finished. They're the testable conditions that have to be true for the story to count as complete. For the CSV export: "all visible columns are included; dates are in ISO format; the file opens cleanly in Excel and Google Sheets; export of 10,000 rows completes within 5 seconds." Without criteria, "done" is an argument; with them, it's a checklist. They also become your test cases almost for free.

What makes a good story

• Small — finishable within a sprint. If it can't be, it's an epic; split it.
• Independent — deliverable without waiting on three other stories where possible.
• Valuable — delivers something a user would notice, not a hidden technical fragment.
• Behavioral, not implementation — it describes what the user experiences, not which function gets called.

Tie stories back to use cases

Each story should trace to a use case and, through it, to a requirement in the PRD. That traceability is what keeps a backlog of stories from drifting away from the problem you set out to solve — every story can answer "which user need am I here for?"