Skip to content
wannacode

Acceptance criteria

In short: Acceptance criteria say when a story is done, before the work starts. They work best as a rule with concrete examples: "free from 50.00 €" plus "49.99 € → 4.90 €, 50.00 € → 0.00 €". The Definition of Done is the shared measure for every story, while the Definition of Ready is a team practice, not part of the Scrum Guide.

Problem

The cancel that always works

The story is "As a customer I want to cancel my order so that I do not pay for something I no longer want." The developer puts a "Cancel" button on every order. QA checks: you press it, the order becomes cancelled. It passes.

A week later a customer cancels an order that is already with the courier. They get their money back, and the parcel arrives at their door. The warehouse asks who decided that a shipped order can be cancelled.

Nobody decided it. Nobody wrote down when cancelling is allowed. The story had a card and a little conversation, but no confirmation.

The idea

When is the story done

Acceptance criteria are the conditions a story has to meet to be accepted. They are the third C, the confirmation, written down.

For cancelling an order:

  • A new order can be cancelled.
  • A paid order can be cancelled before it is shipped. The money goes back to the customer.
  • A shipped, delivered or returned order cannot be cancelled. The customer sees why and how to return the product.

Three lines, and the bug from the start would not have happened. The developer would have known what to build, QA what to check, and the owner what they accept.

The criteria are for one story. They are written before the work, together: the business, QA and the developer. Written after it, they describe what was built, not what was needed.

The idea

Rule and example

A rule on its own is not enough. Two people read "Delivery is free from 50 €" in two ways. So next to every rule go examples with concrete numbers:

Rule: delivery is free for an order from 50.00 € inclusive, otherwise it is 4.90 €.

  • A cart of 49.99 €: delivery is 4.90 €.
  • A cart of 50.00 €: delivery is free.

Rule: the promo code does not apply to discounted products.

  • A t-shirt for 20.00 € and discounted jeans for 40.00 €. With AUTUMN10 the discount is 2.00 €, not 6.00 €.

An example is read one way. Nobody can misunderstand it, and if the rule is wrong, the example shows it: the owner looks at 49.99 € and says "no, I want that one free too".

Remember the form rule and example. In the next module it becomes a Gherkin scenario: there is a keyword "Rule", and under it the examples come as scenarios. There is no syntax here yet, only the habit.

More precisely, if you are curious

ISTQB CTFL v4.0.1 (section 4.5.2) describes two main formats for criteria: scenario-oriented, with "Given / When / Then" as used in BDD, and rule-oriented: a verification checklist or an input → output table. A rule with examples is the bridge between the two.

The idea that examples are the clearest specification is at the heart of Gojko Adzic's book "Specification by Example" (2011). In most sources, the examples that show a rule are called key examples: not every possible one, but the ones that make a difference.

The other syllabi this course follows say the same in their own words. ISTQB CT-AcT v1.0 (acceptance testing) was written together with the business analysis board IQBBA and covers how the analyst and the tester get together from a requirement to the criteria and the acceptance tests. In IIBA's BABOK v3, user stories (User Stories) and criteria (Acceptance and Evaluation Criteria) are separate techniques, and the Agile Extension to BABOK covers business analysis in agile teams.

Try it

Which criterion works?

1. The story: "As a customer I want free delivery on a bigger order." Which criterion works?
2. The story: "As a customer I want to use a promo code." Which criterion describes behaviour, not a screen?
3. The story: "As a customer I want to cancel my order." Which criterion is forgotten most often?
4. Which criterion can be checked?

The idea

The good criterion

An acceptance criterion is a small requirement, so the qualities from the lesson "The good requirement" apply here too. The most important ones:

  • Testable. It can fail a test. "Correctly", "fast" and "convenient" cannot.
  • About behaviour, not a screen. "The code gives 10 %", not "a green button below the total". How it looks is for the team to decide.
  • With the negative cases. What is not allowed, and what the customer sees then. Cancelling after shipping is exactly that.
  • With the boundary. 49.99 and 50.00 €. The 14th and the 15th day. Bugs live around boundaries.

And one rule about the number. If the criteria grow to fifteen, the story is too big. Many criteria means many rules, and many rules are the signal to split.

The idea

Definition of Done and Definition of Ready

The criteria are for one story. There are also measures that apply to every story.

The Definition of Done is the list the team meets for every change, whatever it is. For example:

  • all acceptance criteria are checked;
  • the tests pass;
  • another person on the team has reviewed the change;
  • the help page is updated if something visible has changed.

A story is done when it meets both its own criteria and the Definition of Done.

The Definition of Ready is the opposite check, before the work: the story has a role and a benefit, criteria with examples, no open questions, and fits in a few days.

Here is the usual confusion. The Scrum Guide defines only the Definition of Done, as a commitment for every finished part of the product. The Definition of Ready is not in the Scrum Guide. It is a practice many teams have adopted on their own. It is useful as long as it is a checklist for a conversation. If it becomes a gate a story cannot pass without a signature, the work starts slowly again.

More precisely, if you are curious

The Scrum Guide (the 2020 edition) describes the Definition of Done as the formal description of the state of the Increment when it meets the quality measures required for the product. About readiness it only says that Product Backlog items the team can do within one Sprint are deemed ready for selection. There is no separate list called a Definition of Ready.

Try it

Which is which?

1. "The promo code does not apply to discounted products."
2. "All acceptance criteria are checked and the tests pass."
3. "The story has criteria with examples and no open questions before it goes into work."
4. "Another person on the team has reviewed the change before it is released."

Exercise

Criteria at work

1. From the need to acceptance. Put the path of one story in order.

Put the steps from the need to the accepted story in order.

  1. The team builds the story
  2. You write the story: role, goal, benefit
  3. The owner accepts the story
  4. You write the acceptance criteria
  5. You check against the criteria
  6. The owner states the need
  7. You talk: rules, examples, questions

2. The missing example. Every rule has examples, but not the ones that make a difference.

1. The rule: "Returns within 14 days of receiving the goods." The examples: received on 1 October, requested on 10 October, accepted. Which example is missing the most?
2. The rule: "Delivery is free from 50.00 € inclusive." The examples: 30.00 € → 4.90 €, 80.00 € → 0.00 €. Which example will catch "over 50" instead of "from 50"?
3. The rule: "The promo code does not apply to discounted products." The example: a t-shirt for 20.00 €, with AUTUMN10 it costs 18.00 €. What is missing?

Test

Check yourself

1. When are acceptance criteria written?
2. Why is "rule and example" stronger than a rule alone?
3. What is the difference between an acceptance criterion and the Definition of Done?
4. What is true about the Definition of Ready?
5. A story has 18 acceptance criteria. What does that suggest?

Made by Ivo Gergov as part of Evo Tech's campaign for accessible programming education ·