Telos logo
Telos
Book a Demo
Back to Blog
Product Management Agile Acceptance Criteria User Stories

Acceptance Criteria: Definition, Examples, and How to Write Them

Acceptance criteria define when a user story is done. Here's how to write them well, with real examples in Given-When-Then format and common mistakes to avoid.

Telos Team •
Acceptance Criteria: Definition, Examples, and How to Write Them

Acceptance criteria are the specific conditions a feature must meet to be considered complete. They answer the question: “How will we know when this user story is done?”

Without acceptance criteria, “done” is subjective. Engineering thinks a feature is ready. Product thinks two edge cases are missing. QA finds behaviors no one discussed. Acceptance criteria prevent all of that by making the definition of done explicit before development begins.

What Are Acceptance Criteria?

Acceptance criteria are a set of conditions, written before development starts, that a feature must satisfy to be accepted by the product owner.

Each user story should have at least two to five acceptance criteria. They describe the behavior the system needs to exhibit, from the user’s perspective. They are not implementation details.

Good acceptance criteria:

  • Are testable - you can write an automated or manual test from them
  • Are written in plain language - no jargon, no technical implementation
  • Cover the happy path (expected behavior) and edge cases
  • Are agreed on by product, engineering, and QA before development begins

Acceptance Criteria Formats

There are two main formats teams use.

Given-When-Then (Gherkin)

This is the most widely used format. It structures each criterion as a scenario:

Given [a context or starting condition]
When [an action is taken]
Then [the expected result]

This format is popular because it maps directly to automated test structure. QA can write Cucumber or SpecFlow tests from it word-for-word.

Example:

Given I am a logged-in user When I click “Forgot password” Then I receive a password reset email within 5 minutes

Given I enter an incorrect password three times When I attempt to log in a fourth time Then my account is locked and I see the message “Account locked. Contact support.”

Checklist Format

Simpler and faster to write. Useful for smaller stories where the conditional logic isn’t complex:

  • User can upload files up to 10MB
  • Supported formats: PDF, DOCX, PNG, JPG
  • Files over 10MB show an error: “File too large. Maximum size is 10MB.”
  • Unsupported formats show an error: “Unsupported file type.”
  • Successful upload shows a confirmation message and the file appears in the list

Both formats work. Use Given-When-Then when the behavior is conditional or when QA plans to automate. Use checklist format for simpler stories.

Acceptance Criteria Examples

Login and Authentication

User story: As a returning user, I want to log in with my email and password so that I can access my account.

Acceptance criteria:

  • Given I am on the login page, when I enter a valid email and password, then I am redirected to my dashboard.
  • Given I enter an incorrect password, when I click “Log in,” then I see “Incorrect email or password” - not which field is wrong (for security).
  • Given I enter a valid email that is not registered, when I click “Log in,” then I see the same generic error message.
  • Given I have been inactive for 30 minutes, when I navigate to any page, then I am redirected to the login page.

Search Functionality

User story: As a user, I want to search for items by name so that I can find what I’m looking for quickly.

Acceptance criteria:

  • Given I type at least 2 characters in the search bar, when I pause for 300ms, then results appear below the input.
  • Given my search matches no items, when results load, then I see “No results for [search term].”
  • Given my search returns more than 10 results, when results load, then only the first 10 are shown with a “Load more” option.
  • Given I clear the search bar, when the input is empty, then results disappear and the default view returns.
  • Search is case-insensitive.

Notifications

User story: As a user, I want to receive email notifications when my order ships so that I know when to expect delivery.

Acceptance criteria:

  • Given an order status changes to “Shipped,” when the status update is saved, then an email is sent to the order’s email address within 10 minutes.
  • Given the email address is invalid, when the send fails, then the error is logged and the support team is alerted.
  • Email contains: order number, estimated delivery date, and carrier tracking link.
  • Given I have disabled shipping notifications in settings, when an order ships, then no email is sent.

Form Validation

User story: As a user, I want clear error messages on forms so that I know what to fix before submitting.

Acceptance criteria:

  • Required fields show a red border and an error message below if left blank on submit.
  • Email fields validate format (must contain @ and a domain) on blur (when the user clicks away).
  • Password fields require at least 8 characters and one number. Error shows inline as the user types.
  • A form with errors does not submit - the user stays on the page with errors highlighted.
  • A successful submission shows a confirmation message and clears the form.

What Makes Acceptance Criteria Good

Testable. If you can’t write a test for it, it’s too vague. “The UI looks good” is not an acceptance criterion. “The button is disabled and grayed out until all required fields are filled” is.

From the user’s perspective. Acceptance criteria describe what the user experiences, not how the system implements it. “The system queries the database using an indexed column” is an implementation detail, not an acceptance criterion.

Covers edge cases. Happy path coverage is not enough. What happens when the input is empty? When the network is slow? When the user has no permissions? The edge cases are where bugs hide.

Written before development. If acceptance criteria are written after engineering finishes, they’re just documentation. They need to be written before development begins so they shape the implementation.

Agreed on by all parties. Product writes them, engineering reviews them for completeness, QA reviews them for testability. All three should sign off before a story enters the sprint.

Common Mistakes

Too vague. “The feature works correctly” is not an acceptance criterion. Be specific about what correct means.

Too many per story. If you have 15 acceptance criteria, the story is too large. Break it up.

Only happy path. Most bugs live in the edge cases. What happens with empty input, invalid data, or network errors?

Implementation details. “The API returns a 200 status code” is an implementation detail. “The user sees a success message after submitting the form” is an acceptance criterion.

Written after development. Acceptance criteria written after a feature is built are reverse-engineered requirements, not specifications. They don’t prevent misalignment - they just document what was built.

Acceptance Criteria in Agile Tools

In Jira, acceptance criteria usually live in the ticket’s description or a dedicated custom field. Many teams use a “Definition of Done” template that prompts for acceptance criteria when a new story is created.

In Linear, teams typically add acceptance criteria to the issue description in Markdown format.

Regardless of tool, the important thing is that acceptance criteria are visible to the entire team - product, engineering, and QA - before development begins.

Automating Acceptance Criteria Generation

Writing acceptance criteria from scratch takes time. For every user story in a sprint, a PM needs to think through the happy path, the edge cases, the error states, and the boundary conditions.

Telos generates draft acceptance criteria as part of its ticket creation workflow. When you describe a feature in a planning call or Slack conversation, Telos generates user stories with acceptance criteria already written - in Given-When-Then format. You review and adjust before they go into Jira.

This doesn’t replace judgment. You still decide whether the edge cases are right, whether the acceptance criteria are testable, and whether the story is scoped correctly. But the first-draft work - the blank-page problem - is handled automatically.

Want to see how this works in practice? Book a demo of Telos. And if you’re writing acceptance criteria, you’re probably also working on user story templates and sprint planning - both covered in detail on the Telos blog.