Acceptance Criteria

In Turkish: kabul kriterleri

Updated September 30, 20262 min read

In short

Acceptance criteria are the specific, testable conditions a single user story or backlog item must meet before the Product Owner accepts it as complete.

What are acceptance criteria?

Acceptance criteria are the conditions a specific user story or backlog item must satisfy before it can be accepted as complete. They turn a short story, such as a shopper wanting to reset a password, into clear, testable statements about what the feature must do, for example that the reset link expires after 30 minutes. Each criterion either passes or fails, which removes guesswork about when the story is finished.

The Product Owner, developers, and testers usually agree on the criteria together during backlog refinement or sprint planning, and they are attached to the story itself. Two formats are common: a checklist of rules, and scenarios in the Given-When-Then format, which can be automated as acceptance tests in behavior-driven development. Good criteria describe behavior and outcomes rather than implementation details, cover important edge cases and error situations, and stay few in number; a story that needs fifteen criteria probably should be split.

Acceptance criteria are like the instructions a customer gives a tailor: the sleeves end at the wrist, there are two inside pockets, and the suit is ready by Friday. Developers use them to know when to stop, testers use them to design test cases, and the Product Owner uses them to check the result at the sprint review.

Acceptance criteria are often confused with the Definition of Done. Acceptance criteria are unique to one story and describe what that story must do, while the Definition of Done applies to every item and describes a shared quality bar, such as reviewed code and passing tests. A story is only complete when it meets both. They also differ from acceptance testing: the criteria are the conditions, and acceptance tests are the checks that verify them.

Key takeaways

Acceptance criteria are pass-or-fail conditions for one specific story.
They are agreed before development starts, usually during refinement.
Common formats are rule checklists and Given-When-Then scenarios.
They describe what the feature does, not how it is built.
The Definition of Done applies to all work; acceptance criteria apply to one item.

Example

Acceptance criteria for a user storytext

Story: As a shopper, I want to reset my password, so that I can log in again.

Acceptance criteria:
  1. The "Forgot password?" link on the login page opens the reset form.
  2. Given a registered email, when I submit the form,
     then I receive an email with a reset link within 2 minutes.
  3. The reset link works only once and expires after 30 minutes.
  4. The new password must have at least 12 characters.
  5. For an unknown email, the page shows the same confirmation message,
     so attackers can't tell which emails are registered.

Readers ask

Who writes acceptance criteria?

The Product Owner is usually responsible for them, but they work best when written together with developers and testers, who spot missing cases and check that each criterion can be tested.

What is the difference between acceptance criteria and the Definition of Done?

Acceptance criteria are specific to one user story and describe its required behavior. The Definition of Done is a single checklist of quality standards that applies to every story the team delivers.

What is a good format for acceptance criteria?

A short numbered list of rules works for simple stories, while Given-When-Then scenarios work well for behavior with several steps or conditions. Either way, each criterion should be clear and testable.