What acceptance criteria do
A user story says what a user needs. Acceptance criteria say how you’ll know you delivered it. They turn a one-line story into something a developer can build against and a tester can check, without a long spec.
Criteria also mark the edges of a story. Anything they don’t cover is out of scope, which keeps stories small and estimates honest. Good criteria are:
- Testable: each one passes or fails, with no judgment call.
- About behavior: they describe what the user sees or the system does, not how it’s coded.
- Specific to the story: rules that apply to all work belong in the Definition of Done.
- Short: if you need more than a handful, the story is probably too big.
Who writes acceptance criteria
The product owner or product manager usually drafts them, since they own the what and the why. The best criteria come out of a short conversation between product, a developer and a tester, a practice often called the three amigos. Product brings the intent, engineering spots edge cases and constraints, and QA asks how each rule will be verified.
Write them during backlog refinement, before Sprint Planning. A story without agreed criteria isn’t ready to pull into a sprint.
How to write acceptance criteria for a user story
Work from the story outward. A few steps cover most cases:
- Reread the “so that” clause and list what must be true for that benefit to happen.
- Write the happy path first, then the failure cases: invalid input, missing permissions, timeouts.
- Phrase each criterion as an observable result, not an implementation step.
- Read them back with a developer and a tester, and rewrite anything two people could read differently.
- Move anything that applies to every story into the Definition of Done.
The Given/When/Then format
Given/When/Then comes from behavior-driven development (BDD) and is the basis of Gherkin, the syntax used by test tools like Cucumber. Each scenario describes one behavior in three parts. Use “And” to extend any step, and write separate scenarios for failure cases, not only the happy path.
- Given: the starting context or state.
- When: the action or event.
- Then: the expected, observable result.
Rule-based checklists
Not every story needs scenarios. When rules are independent of each other, a plain checklist is faster to write and just as clear. Use Given/When/Then when behavior depends on state or sequence. Mixing both in one story is fine. Here’s a checklist for a story about exporting a report to CSV:
- The Export button appears on every report.
- The CSV includes the columns shown in the current view, in the same order.
- Dates use the YYYY-MM-DD format.
- Exports over 50,000 rows are emailed as a link instead of downloaded.
Acceptance criteria vs requirements
Requirements describe what a product must do overall, often across many features. Acceptance criteria are narrower: they apply to one story and define when that story is accepted. Think of them as requirements cut down to the size of a single backlog item and written so they can be tested.
They also differ from the Definition of Done, which applies to every item. “Invoices show tax per line” is an acceptance criterion. “Code is reviewed and tests pass” belongs in the Definition of Done.
Acceptance criteria in NoaBox
When you attach a PRD, spreadsheet or CSV in Ask Noa, it drafts work items with priorities and acceptance criteria as proposals. You review and confirm each one before anything is created, so every criterion still gets a human check.
See how Noa works