Acceptance Criteria

Close

A user story needs enough detail for the team to know when it is done.

That detail may take the form of acceptance criteria, examples, tests, rules, sketches, or notes. The format matters less than the shared understanding it creates.

What Are Acceptance Criteria?

Acceptance criteria are details that help a product owner and team confirm whether a story has been completed correctly.

They usually describe important behavior, rules, examples, constraints, or outcomes. They are not meant to be a full test plan. They should give the team enough guidance to build and evaluate the story.

For example, consider this story:

As a conference attendee, I can save sessions to a personal agenda so that I can plan which sessions to attend.

Possible acceptance criteria:

  • A logged-in attendee can add a session to a personal agenda.
  • A saved session is shown as saved.
  • The attendee can remove a saved session.
  • If two saved sessions occur at the same time, the attendee is warned of the conflict.

Those bullets help the team understand what matters. They also invite better questions.

Keep Acceptance Criteria Useful

Acceptance criteria should help the product owner and team understand what would make the story acceptable. They should not become a formal checklist someone hands to testers after the real conversation is over.

The product owner does not need to document every test. The product owner should make clear the important rules, examples, and outcomes that would cause the story to be accepted or rejected. The team can then turn those concerns into tests, examples, automation, exploratory testing, or other verification work.

Add Detail Progressively

Stories are deliberately vague when they are first written.

That vagueness is useful. It keeps the team from wasting time specifying details for work that may change, move down the backlog, or never be done.

As a story moves closer to implementation, the team adds detail. The product owner clarifies business rules. Developers identify technical risks. Testers suggest examples. Designers sketch alternatives. Stakeholders expose edge cases.

Detail should support a decision.

A story low in the backlog may need only a sentence and a rough sense of value. A story near the top needs enough detail that the team believes it can be completed in a sprint.

Two Ways to Add Detail

There are two common ways to add detail to a story.

First, split the story into smaller stories. A large story such as "As a shopper, I can use coupons" may be split by coupon type, rule, customer type, checkout path, or error condition. Each smaller story adds detail by making a slice of the original idea explicit.

Second, add acceptance criteria. These might describe rules, examples, constraints, or expected behavior within a story.

Both approaches can be useful. When the story is too large, split it. When the story is small enough but unclear, add confirmation details.

What Good Acceptance Criteria Look Like

Good acceptance criteria are clear, relevant, and useful.

They usually answer questions such as:

  • What must work for the story to be accepted?
  • What rules matter most?
  • What examples would expose misunderstanding?
  • What edge cases are important enough for this story?
  • What is intentionally out of scope?

They should not become a dumping ground for every possible test, every design detail, or every technical task.

For a payroll story, an acceptance criterion might say:

  • The list includes employees with at least one unapproved time entry in the current pay period.

That is useful because it clarifies the rule. It does not specify every UI element or every test case.

How Much Detail Is Enough?

Enough detail depends on where the story is in the backlog and what decision the team is trying to make.

Before a story enters a sprint, the team should understand what must be true for the item to be considered complete. That does not mean every edge case has been documented. It means the team and product owner have enough shared understanding to start work responsibly.

Too little detail causes rework, surprises, and missed expectations.

Too much detail too soon causes waste. It can also reduce the team's ability to find a better solution.

A useful question is: What conversation would help the team most right now?

Acceptance Criteria, Definition of Done, and Tests

Acceptance criteria apply to a specific story.

The Definition of Done applies more broadly. It describes what generally must be true for completed work, such as code reviewed, tests passing, documentation updated when needed, and integrated into the product.

Tests are more detailed ways of verifying behavior. Some may come directly from acceptance criteria. Others come from testers, developers, automation, exploratory testing, regression suites, or quality practices.

Do not make one of these carry the work of all three.

Be Careful with Definition of Ready

Some teams create a Definition of Ready for stories. A lightweight readiness conversation can be helpful. A rigid Definition of Ready can create problems.

If a Definition of Ready becomes a gate, the team may over-refine work too early. The product owner may feel pressured to provide more detail than is useful. Developers may avoid helpful ambiguity until every question has been answered.

A better habit is to keep refinement conversational. Ask whether the team understands the story well enough to bring it into a sprint, and identify the next conversation if it does not.

Common Acceptance Criteria Problems

Acceptance criteria should clarify the conversation, not replace it.

Adding Too Much Detail Too Soon

Teams waste effort when they document every possible rule before the story is close enough to build. For more detail, see Adding Detail to User Stories.

Writing Tasks Instead of Outcomes

Acceptance criteria should describe what must be true for the user or product, not every implementation step. For more detail, see Good User Stories.

Confusing Acceptance Criteria with Definition of Done

Acceptance criteria are specific to one item. Definition of Done describes quality expectations that apply across work. For more detail, see Definition of Done.

Using Criteria as a Gate Instead of a Conversation

Criteria help when they invite discussion. They hurt when they become a checklist for avoiding collaboration. For more detail, see Adding Detail to User Stories.

FAQ

Who writes acceptance criteria?

The product owner should make the important acceptance concerns clear, but the team should help. Developers, testers, designers, analysts, and stakeholders often spot missing examples or rules the product owner has not considered.

Are acceptance criteria the same as test cases?

No. Acceptance criteria are usually higher-level. Test cases are more detailed. A single acceptance criterion may lead to many tests.

Do all stories need acceptance criteria?

Most stories need some confirmation detail before they are brought into a sprint. The form can vary. Some teams use bullets. Some use examples. Some use Given/When/Then. Some use sketches and notes.

Can acceptance criteria be added after development starts?

Yes, but that should be intentional. New information often appears during development. The risk is discovering basic acceptance expectations too late because the team skipped an important conversation.

How many acceptance criteria should a story have?

As many as are useful and no more. If the list is long, the story may be too large or the team may be documenting test cases rather than acceptance concerns.

A Lightweight Confirmation Routine

A simple routine can keep acceptance criteria useful.

First, ask what would cause the product owner to reject the story. This usually reveals the most important acceptance criteria. The answer may involve a business rule, a user-visible behavior, a compliance constraint, a performance expectation, or a missing edge case.

Second, ask for one or two examples. Examples expose hidden assumptions better than abstract statements. If a rule says discounts apply to eligible customers, ask for examples of eligible and ineligible customers. If a report should include active employees, ask what counts as active.

Third, ask what is out of scope for this story. Out-of-scope notes are often as useful as acceptance criteria because they protect the team from quietly expanding the work during the sprint.

Fourth, decide whether the list is too long. A long list of acceptance criteria may signal that the story is too large. Some acceptance criteria may deserve to become separate stories.

What to Avoid

Avoid treating acceptance criteria as a contract written before the team learns anything. They should guide the conversation, not end it.

Avoid copying every possible test into the story. Detailed tests belong in the team's testing approach. The story should capture the conditions that matter to acceptance.

Avoid letting acceptance criteria hide the user goal. If the criteria are longer than the story and no one can remember the outcome, the story may have turned into a small requirements document.

Avoid waiting until the end of the sprint to discuss acceptance. Confirmation details should be understood before the team has invested too much effort in the wrong direction.