Acceptance Criteria That Survive a Sprint Review

What an acceptance criterion actually is, six weak ones shown as they arrived and as they went out, and the three objections a reviewer raises first.

The criterion said the refund decision comes back in under 48 hours. It went through refinement without a single comment. It came back at the sprint review with two people disagreeing about whether it was done. One of them had started the clock when the customer pressed submit. The other had started it when the case was logged for review. Both readings fit the sentence, and the gap between them was most of a working day.

An acceptance criterion is a single testable statement of what has to be true before a piece of work counts as done, written so that somebody other than the author can check it. The sentence above satisfied every part of that except the last, and the last is the part that costs you the meeting.

That criterion was mine, on a real project with a real team. The returns case published here is a different thing: no client, no engagement, built from published policy and public complaint threads. I put the same criterion into it, and the same objection, because the mistake travels and the fix travels with it.

In short

• Format is not what fails. Criteria fail on the start event, on the branch where the rule does not fire, and on where the number came from.
• A duration with no start event is half a requirement: submitted and received are not the same moment, and the team will pick whichever one is easier to build.
• If only the success path is written down, the failure path is being designed by whoever picks up the ticket.
• A threshold with no id, no owner and no date gets renegotiated mid-build by whoever sits closest to the keyboard.

Format was never the problem. I have watched Given/When/Then pass one review and fall apart in the next. Format is what the criterion is wearing. Three things underneath decide whether it survives.

What makes a criterion testable?

Can anyone test this without asking me?

If the tester has to walk over and ask what I meant, the sentence is not a criterion. It is a note to myself, filed in a document other people work from. Words that fail this on sight: quickly, user friendly, accurate, appropriate, seamless. Each one describes how I feel about the outcome, not the outcome.

If a criterion only works while I am in the room, what I wrote down was a memory.

When does the clock start?

Any criterion with a duration in it has a hidden second half. Within 48 hours of what? Same day in which timezone, and does Saturday count? A duration with no named start event is two requirements pretending to be one, and if I leave it open the team picks the start event for me, usually the one that is easiest to build.

Who owns the path where it goes wrong?

On the first pass I describe the case where the system behaves. The money is in the other branch. If the decision does not arrive, if the upload fails, if the provider times out, something still has to happen. A shared queue is where a case goes to stop being anybody's problem, so the exception needs a name against it, not an inbox.

Six criteria, as they arrived and as they went out

The numbers below stand in for whatever your own business rule says. The shape is the point.

Payments

Weak: The payment is processed quickly and the user sees a confirmation.

Fixed: When the card authorisation returns approved, the order becomes Paid and the confirmation screen renders within 3 seconds of that response. If no response arrives within 30 seconds of submission, the order moves to Pending review and the customer sees the "we are still checking this" screen, not a payment error.

What changed: quickly got a start event, and the timeout stopped being an error message and became a state with its own outcome.

Refunds

Weak: The refund decision is returned within 48 hours.

Fixed: The 48 hour clock starts at the timestamp on the submitted refund form, not at the moment the case is received. If no decision is recorded by then, the case goes to a named duty manager and appears in their personal queue.

What changed: the clock got a start event, and the miss got a person instead of a shared inbox.

Registration

Weak: The registration form is user friendly and validates the data.

Fixed: Submitting the form with an email address that already exists does not create a second account. The user stays on the form, the other fields keep their values, and the message reads "this email is already registered" with a link to password reset.

What changed: a judgement nobody can fail became a case anyone can run in twenty seconds.

Notifications

Weak: The user gets a notification when their order status changes.

Fixed: Every transition into Shipped, Delayed or Cancelled sends one email to the address on the order, within 5 minutes of the transition. A repeated transition into a status the order already had sends nothing. A user who has turned off order emails in settings receives none of the three.

What changed: "changes" was hiding three decisions, so all three are on the page: which transitions count, what repeats do, and what the opt-out switches off.

Reporting

Weak: The monthly sales report shows accurate data.

Fixed: For a closed month, the total equals the sum of order lines with status Invoiced and an invoice date inside that month, converted at the rate stored on the invoice rather than today's rate. An order invoiced in March and credited in April stays in March, and April shows the credit.

What changed: accurate became which rows, which date and which rate. Two people working separately land on the same number, or find out where they diverged.

Permissions

Weak: Only authorised users can access the admin panel.

Fixed: A signed-in user without the Admin role who opens /admin/users is returned to their dashboard with "you do not have access to this page", and the attempt is written to the audit log with user id, path and timestamp. A user whose Admin role is removed mid-session loses access on the next request, not at next login.

What changed: authorised became a named role, the refusal became visible and logged, and the mid-session case got answered before an auditor asked.

The sheet I run before I send anything

Five lines, about half a minute per criterion.

The last line is the one I used to skip. Writing "open question: the 90 day retention period, to be checked against the statutory limits, owner legal, due before build starts" costs nothing. Guessing 90 days quietly, and having the guess hold until somebody reads the contract, is expensive.

What will a reviewer object to first?

Three objections come back more often than the rest, and answering them inside the document is cheaper than answering them out loud.

"That is a design decision, not a criterion"

Usually correct. If the criterion names a dropdown, a button colour or a database column, I decided how instead of what, and locked the team out of a better answer. "The customer can start the refund without calling support" is a criterion. "There is a Refund button in the top right of the order page" is a design decision wearing the same costume. I answer it in advance with a Mechanism line under the criterion, marked as a suggestion and not a constraint.

"You have written the happy path again"

The tell is that every criterion in the story ends in success. A reviewer caught this on a process model where I had drawn no parked branch at all, which made my proposed flow look better than it was. Now I count: one exception line per criterion, or a sentence putting the exception out of scope with a name against it. An exception you excluded on purpose is a decision. An exception you did not notice is a defect with a delivery date on it.

"Where does that number come from?"

The 48 hours, the 40 EUR order value, the three files at 10 MB each. Someone always asks, and rarely in a room I would have chosen. If the answer is "it seemed reasonable", the number gets renegotiated mid-build by whoever sits closest to the keyboard. If the answer is "business rule 11: published policy, the rationale written down and marked as my inference, the owner slot open as OQ-03 rather than filled in with a plausible department", the question is finished, and it is finished even though nobody could name the person who set it. Every threshold gets an id, an owner and a date, or it goes down as an open question.

Does Given/When/Then settle any of this?

Not on its own. It pushes you towards a trigger and an outcome, and says nothing about when the clock starts or who catches the case when the rule does not fire. A plain numbered list that answers those two outlives a beautifully formatted set that leaves them open. Pick the format your team reads; the two questions underneath it are the work.

Take three criteria you have already written and run the five checks before your next review. If one of them means two different things depending on who reads it, that is the one that was going to cost you the meeting.

The refund criteria above come from the worked case on this site. "Testable without asking the author" is check 02 of the twenty-five in the scorecard that goes with it, which you can download without giving me an email address. If you want the register those criteria sit in, the six artifacts a reviewer looks for is the longer piece.

All field notes · The portfolio guide · More in Requirements That Survive Review