How to Write User Stories With Acceptance Criteria (Templates and Examples)

You wrote what seemed like a clear request. Two weeks later, the feature arrives and it is not what you meant. The button exports a CSV, not a PDF. It works for admins but not managers. Nobody thought about what happens when the list is empty. Now there is another round of questions, fixes and retesting.

Most of that back-and-forth comes from vague user stories. A good user story explains who needs something and why, and its acceptance criteria spell out exactly what “done” looks like. This guide gives you templates, good-versus-bad examples and a simple checklist you can use on your next backlog.

What a user story is (and isn’t)

A user story is a short description of a capability, written from the point of view of the person who benefits from it. User stories come from Extreme Programming, and the Agile Alliance describes them as small functional increments that each add value to the product.

A user story is not a full specification. It is a placeholder for a conversation. That idea is often summarized as the “3 C’s“:

• Card: a short written statement of the need.
• Conversation: the discussion between product, design, development and testing that fills in the details.
• Confirmation: the acceptance criteria that confirm the story works as intended.

Teams still need broader documents for some projects, such as compliance rules or system-level requirements. Our guide on how to write a software requirements document covers when a fuller spec makes sense. Stories then break that work into deliverable pieces.

The user story template

The most common template is:

As a [type of user], I want [goal or action] so that [benefit or reason].

Each part does a job:

• The user tells the team whose experience they are designing for. Be specific: “returning customer” or “warehouse manager”, not just “user”.
• The goal describes what the user wants to do, not how the system should do it.
• The benefit explains why it matters. It helps developers make smart trade-offs and helps product owners prioritize.

Example:

As a returning customer, I want to reorder a past purchase from my order history so that I can restock without searching for each item again.

Some teams also use a “job story” format, “When [situation], I want to [motivation], so I can [outcome]”, which focuses on context rather than user roles. Either works if the team uses it consistently.

How to write acceptance criteria

Acceptance criteria are the specific, testable conditions a story must meet to be accepted. They remove guesswork for developers and give testers a ready-made checklist.

There are 2 common formats.

Format 1: Rule-based checklist

A simple bulleted list of conditions. Good for straightforward stories.

• The “Reorder” button appears on every past order in order history.
• Clicking “Reorder” adds all items still in stock to the cart at their current prices.
• Items no longer sold are listed in a message and are not added.
• The customer is taken to the cart after reordering.

Format 2: Given-When-Then scenarios

This format describes behavior as scenarios. It comes from behavior-driven development and is written in Gherkin, the language used by tools such as Cucumber. According to the Cucumber documentation, Given sets up the starting context, When describes the action or event, and Then describes the expected, observable outcome.

Scenario: Reorder with an out-of-stock item Given I am signed in as a returning customer And my past order contains 3 items, 1 of which is out of stock When I click "Reorder" on that order Then the 2 in-stock items are added to my cart at current prices And I see a message naming the out-of-stock item

Given-When-Then works well for stories with several paths or edge cases, and the scenarios can become automated tests. If your team practices test-driven development or behavior-driven development, this format plugs straight into that workflow.

Tips for strong acceptance criteria:

• Aim for roughly 3 to 7 criteria. If you need 15, the story is probably too big.
• Describe outcomes, not implementation (“customer sees a confirmation”, not “call the confirmOrder API”).
• Cover the unhappy paths: empty states, errors, permissions and invalid input.
• Make each criterion testable with a clear pass or fail.
• Include relevant non-functional needs, such as “page loads in under 2 seconds on a typical connection” or accessibility requirements.

Key takeaway: The user story explains who needs something and why; the acceptance criteria define exactly what done looks like. Most back-and-forth with developers disappears when every story has testable criteria covering both the happy path and the edge cases.

Good versus bad user story examples

And a full good example with criteria:

Story: As a clinic receptionist, I want to send appointment reminders by text so that fewer patients miss their appointments.

Acceptance criteria: - Reminders are sent automatically 24 hours before each appointment. - Patients who have not given SMS consent do not receive texts. - The message includes date, time, clinic name and a reply option to confirm or cancel. - A “C” reply marks the appointment as confirmed in the schedule. - Failed deliveries are listed on the receptionist’s dashboard.

Check stories with INVEST

The INVEST checklist, introduced by Bill Wake in 2003 and popularized in Mike Cohn’s book User Stories Applied, is a quick way to judge a story. A good story is:

If a story fails the “Small” or “Estimable” test, split it. Good ways to split include by workflow step (search, then filter, then sort), by user role, by business rule, by data type, or by happy path first and edge cases next. Smaller stories also make software estimation far more reliable.

Where to start: a step-by-step process

1. Start with the user and the problem. Talk to customers or front-line staff, and write down the real goal before any solution.
2. Draft the story using the “As a, I want, so that” template.
3. Add acceptance criteria as a checklist or Given-When-Then scenarios, including at least one unhappy path.
4. Run the INVEST check and split anything too large or vague.
5. Hold a refinement conversation with a developer and a tester. Ask “what could go wrong?” and “what are we assuming?” Update the criteria with what you learn.
6. Attach supporting details such as designs, sample data or business rules, linked rather than pasted into the story.
7. Agree on the Definition of Done for the whole team, covering things like code review, tests and documentation, so you don’t repeat them in every story.
8. Bring ready stories into planning. Our guide to sprint planning shows how to pick and commit to them.

Common mistakes to avoid

• Writing stories alone and handing them off. The conversation is where misunderstandings get caught.
• Using “As a user” for everything. Specific roles lead to better design decisions.
• Skipping the “so that”. Without the reason, developers can’t suggest simpler alternatives.
• Mixing acceptance criteria with the Definition of Done. Criteria are specific to the story; the Definition of Done applies to all stories.
• Writing technical tasks as stories. Track them as tasks under a story, or as enabler work, so the backlog stays focused on value.
• Over-detailing far-future stories. Add detail as a story gets closer to development; early stories can stay rough.

Conclusion

Good user stories are short, specific about who benefits and why, and backed by testable acceptance criteria that cover both the happy path and the edge cases. Use the “As a, I want, so that” template, choose a checklist or Given-When-Then for criteria, test each story against INVEST, and always talk it through with the people who will build and test it. Do that consistently and you will spend far less time on clarifications and rework. Whether you run Scrum or Kanban, the same habits apply, and they are a core skill for anyone looking to become a product manager.

Sources

• Agile Alliance Glossary: User Stories — origins in Extreme Programming, templates and common pitfalls
• Agile Alliance Glossary: INVEST — INVEST criteria, Bill Wake (2003) and Mike Cohn’s User Stories Applied (2004)
• Cucumber Documentation: Gherkin reference — Given, When and Then keywords and scenario structure