Product & DesignFree
User Story Acceptance Criteria Template
Every story gets criteria written as concrete examples, and every question that has to be answered before anyone can estimate it gets an owner.
River reads the spec rather than asking you to summarise it. The PRD, the technical constraints and whatever design exists go in, and what comes back is a story sheet: one row per story, each with acceptance criteria written as concrete examples rather than restatements. Beside it sits the shorter and more useful list, the questions that have to be answered before any of these can be estimated, each one carrying the person who has to answer it and the date it is needed by.
Refinement rarely stalls on how a criterion is phrased. It stalls because somebody asks what happens when the invite goes to an address that already has an account, and nobody in the room can answer. Cucumber's own Gherkin reference recommends three to five steps per example, because an example that sprawls stops working as a specification. The templates ranking for this query give you the Given-When-Then form and nothing that finds the unanswered question.
Built for the product manager writing stories the night before refinement, and for the team that keeps carrying the same story into a third sprint. Reach for it once the spec is agreed and before the estimation meeting where it will otherwise fall apart. The spec itself is the PRD template. What the stories add up to over a quarter is the roadmap template. The evidence a requirement rests on comes from research synthesis.
Why the same story keeps coming back to refinement
Acceptance criteria and the definition of done are different objects, and conflating them is the most common defect in a story sheet. The Scrum Guide describes the definition of done as a formal description of the increment's state. An item that does not meet it cannot be released or even presented at the Sprint Review. That is one standard for everything the team ships. Acceptance criteria are what makes this particular story correct, and they belong on the story.
Take one story: a user invites a teammate by email. The criteria write themselves until you ask what happens when that address already belongs to an account in another workspace. Do they join both, get refused, or get a choice? Nobody owns that answer, so the story gets a number anyway and comes back in sprint three. The sheet puts that question in its own row, names the person who decides, and marks the story unestimable until they do.
The second defect is a criterion that cannot fail. Given a user is logged in, when they click save, then the record is saved is not a test; it is the story with different punctuation. A criterion earns its place by naming a concrete input and a specific observable result, so a person or a test can run it and get a clear answer. Every criterion here is written that way, and the ones that were restatements are shown as what they replaced.
How it works
Hand over the spec
The PRD, the technical constraints, and whatever design or API documentation already exists.
Split into stories
Each one a change a user can notice, sized so a single sprint can hold it.
Write testable criteria
Concrete inputs and observable results, with the edge cases the spec left implicit written out.
Flag the blockers
The questions that have to be answered before estimation, each with an owner and a date.
What you get
- One row per story, with criteria written as concrete examples rather than restatements
- The decisions blocking estimation, each with the person who has to make it
- Edge cases surfaced from the spec, including the ones the spec never mentioned
- Dependencies between stories, so the sequencing argument happens before the sprint rather than during
- Team-wide definition of done kept separate from the criteria specific to one story
- Every criterion traceable back to the requirement in the spec that produced it
Common questions
Do I have to use Given-When-Then?
No. The form is a default because it forces a concrete input and an observable result, and Cucumber's reference recommends keeping an example to three to five steps for exactly that reason. A checklist works too, provided each line can fail. The sheet uses whichever form you ask for and applies one test to both: could a person run this and get a clear answer.
How does it know an edge case the spec never mentioned?
By working the state space of what the story touches rather than the sentences in the document. An invite flow has an address that already exists, an expired link, a revoked seat and a full plan, whether or not the PRD said so. Each one is raised as a question against the story it affects, not asserted as a requirement you never asked for.
Will it estimate the stories for me?
No, and that is deliberate. An estimate from something that has never worked in your codebase is a number with no basis, and it displaces the conversation the team needs to have. What it does instead is remove the reason estimation stalls, by listing what has to be decided first and who decides it. Where the blocker is effort rather than an open question, the feasibility brief prices it.
Where does the definition of done fit?
It sits once, at the top, and applies to every story. Test coverage, accessibility, documentation and release notes are team standards rather than facts about one story, and repeating them per row is how a story sheet becomes unreadable. Anything specific to one story stays in that story's criteria. Performance and reliability belong in neither place, and are gradeable only once they carry a measurement method and a percentile.
Can I import this into Jira or Linear?
The sheet is built to paste in. One row per story with the summary, description, criteria, dependencies and blocking questions in separate columns, so a CSV import maps without rewriting. The blocking questions come out as their own list, because they are usually not tickets and they need an answer before the tickets are worth creating.
What if my spec is thin?
Then the blocking-questions list is long, which is the useful answer. A thin spec does not produce thin stories; it produces stories with unanswered questions attached, and seeing forty of them is what sends the spec back. To write the spec properly first, the PRD template links every requirement to its evidence.
User Story Acceptance Criteria Template
Fill in the form and your workspace opens with the work already underway.