L1Core4 min read

Refinement, acceptance criteria and the three amigos

Testing starts before the code exists. Sitting in refinement, turning a vague story into acceptance criteria somebody could actually verify, and asking the one question that stops a week of work going the wrong way. The cheapest testing you will ever do.

Acceptance criteria are the conditions a piece of work must meet before anyone agrees it is finished. They belong to the story, they are agreed before the code exists, and they are what testing checks against.

Refinement is the meeting where the team turns a rough request into work it can actually build. Some teams call it backlog refinement or grooming. It is where those criteria get written.

The three amigos is the habit of having three points of view in that conversation: business, development and testing. The tester's job there is not to agree. It is to ask what would make this checkable.

This is the cheapest testing you will ever do, because the defects you prevent cost a sentence rather than a sprint.

The terms you will hear

Acceptance criteria. The conditions for accepting a story. Also called AC.
Definition of ready. What a story needs before entering a sprint, usually criteria plus test data notes.
Definition of done. What must be true before a story is finished, applied to every story alike.
Given, When, Then. A format for writing one criterion as a scenario. Also called Gherkin.
Three amigos. Business, development and testing looking at the same story together.
Refinement, grooming. The meeting where stories get clarified, sized and made ready.

Why it matters

Because a vague criterion becomes an argument at the end of the sprint, when it is expensive.

For example, a story says "the customer can redeem a gift card". Nobody wrote down what happens when the card covers only part of the order. The engineer picks one behaviour, the tester expects another, and the disagreement surfaces on day nine with a release on Thursday.

Ten seconds of asking in refinement prevents it. That is the entire economic argument, and it is why the tester in the room is worth their seat.

How to write criteria that can be tested

Start from the outcome, not the screen. What must be true afterwards, from the user's point of view.
One condition per criterion. If it contains "and", it is probably two.
Make every result observable. A number, a message, a state, an email. If you cannot see it, you cannot test it.
Cover the three that get forgotten. The empty case, the failure case, and the limit. For example: no cards, payment declined, the maximum amount.
Use Given, When, Then when the flow matters. It is a format rather than a religion, and a plain checklist is fine for simple rules.
Note the test data you will need. A seeded card, a customer with two orders. It is what makes a story genuinely ready, and it feeds the test plan.
Read them back out loud. Anything you cannot say plainly is not agreed yet, and that discovery is the value of the meeting.

A defect found in refinement costs a sentence. The same defect found on the last afternoon of the sprint costs the release.

Worked examples, both formats

Here is one story from the gift-card release at Willow Books, written twice.

acceptance-criteria-gift-cards.md

STORY   WB-1802  "As a customer I can pay with a gift card at checkout"

WEAK CRITERIA (what the ticket arrived with)
  - gift cards work at checkout
  - the balance updates
  - errors are handled

  every line is unarguable and untestable. three people would test
  three different things.

CHECKLIST FORM (what we agreed in refinement)
  1  a valid code reduces the amount to pay by the card balance
  2  where the balance is less than the order total, the remainder is
     charged to the payment method, and the card balance becomes 0.00
  3  where the balance is more than the order total, the order is fully
     paid and the remaining balance stays on the card
  4  the card is consumed before the payment method is charged
  5  an invalid or already-spent code shows "This code cannot be used"
     and does not change the order
  6  a code cannot be used twice, including from two browser tabs
  7  the order confirmation lists both payment lines separately

GIVEN WHEN THEN FORM (the one criterion worth spelling out)
  Given a customer with an order totalling 35.99
    And a gift card with a balance of 25.00
  When the customer applies the gift card at checkout
  Then the amount to pay shows 10.99
    And the gift card balance shows 0.00
    And the card is charged only 10.99

QUESTIONS THAT CAME OUT OF WRITING THIS
  can two gift cards be used on one order?      product said no, this release
  what happens at expiry?                        no expiry yet, out of scope
  is a refund returned to the card or the card
    payment?                                     split proportionally, new rule

TEST DATA NEEDED
  4 seeded customers, 2 gift cards (25.00 and 100.00), 1 spent card

Criterion 6 and the three questions are the yield from about eight minutes of conversation. The two-tabs rule became a real defect later, and it was already written down, so nobody argued about whether it counted.

How to show you know it

A weak-to-strong rewrite like the one above, from your own backlog.
A question that changed the scope. "Can two cards be used at once?" is worth more than a week of testing.
Criteria that name the failure case. Most stories only describe success, so this is the fastest way to stand out in refinement.
A story you sent back as not ready. Done politely and with a reason, it is a senior move rather than an obstruction.

Questions

What is the difference between acceptance criteria and test cases?

Criteria state the condition to be met and belong to the story. Test cases are how you check it, with data and steps, and belong to the suite. One criterion usually produces two or three cases, which is the path in writing test cases.

Do we have to use Given, When, Then?

No. Use it where the sequence matters or where the team already speaks it. A numbered checklist is easier to scan and perfectly acceptable for straightforward rules.

Who writes them?

Whoever owns the story writes the first draft, usually product. The tester makes them testable. That split works better than either party doing it alone.

What if the team refuses to spend time on refinement?

Ask two questions per story in whatever meeting exists, and record what the answers change. After a few sprints you have evidence, which is a better argument than principle. It pairs with where the sprint time goes.