Acceptance Criteria: Write Testable Conditions for a Checkout Story

Acceptance criteria describe the behavior a specific story must deliver for its agreed scope to be satisfied. Write them as conditions a reviewer can observe: what is shown, what action is possible, and what happens when the action cannot succeed. For an order-review story, that means specifying the totals, delivery changes, and error states before payment.

A shared product-planning workspace helps product, design, engineering, and QA discuss those conditions together. The checkout example below develops a short set of criteria, turns them into Given–When–Then scenarios, and separates them from the Definition of Done and work outside the story.

Start with the outcome and scope

Use a story that identifies what the person needs to achieve: “As a returning customer, I want to review my order before payment so that I can correct mistakes.” For this example, the customer is signed in, has items in the cart, and has a saved delivery address. The story covers the review step of an existing checkout, not account creation or a new payment integration.

Decide which corrections the step supports. Here, the customer can choose an available delivery method and go back to edit the cart or address. Removing items directly from the review step, adding a promotion code, and redesigning the payment provider are separate decisions. Without that boundary, “correct mistakes” can expand into several features that different people assume are included.

A draft criterion such as “the customer can review everything” hides these choices. Replace “everything” with the actual fields and permitted actions. This gives design something to represent and QA something to check without prescribing how engineering stores the data.

Replace vague words with observable conditions

“The checkout should be easy” is a goal, but two reviewers may interpret it differently. For this story, agree on the following conditions:

1. Order summary: before continuing to payment, the customer sees each item's name, quantity, and price, plus the subtotal, delivery charge, tax amount, currency, and total.
2. Delivery change: choosing another available delivery method refreshes the delivery charge and total before the customer continues.
3. Incomplete or unavailable delivery: when required address information is missing or the selected method is unavailable for that address, the customer sees the problem and how to change the address or method; continuing to payment is blocked.
4. Price refresh: while a delivery-price request is pending, or if it fails, the customer cannot proceed using a stale total. A failure provides a retry action and retains the cart details.
5. Correction path: returning to edit the cart or address preserves the rest of the order. On returning to review, the summary reflects the updated data.

These conditions describe this example's intended behavior. The product team still owns decisions such as supported delivery methods, tax calculation, and whether an address is eligible. The criteria should refer to those agreed rules; they should not invent a new tax or delivery policy.

Use concrete test data to remove arithmetic ambiguity. In a sample fixture, two items at $20 each produce a $40 subtotal. Standard delivery is $5 and the tax amount returned for the fixture is $4, so the displayed total is $49. An express-delivery fixture returns delivery of $9 and tax of $4, giving a $53 total. These are fixed example inputs, not a tax-rate rule; the purpose is to check that the review step displays the returned amounts consistently.

Separate acceptance criteria, Definition of Done, and exclusions

Acceptance criteria apply to the particular behavior under discussion. The Definition of Done describes the quality required of the product Increment in Scrum. Scrum.org distinguishes story-specific acceptance criteria from the Definition of Done: specifying the intended feature does not replace the team's shared quality standard.

Keep exclusions beside the story, but do not count them as passing acceptance criteria. “Payment-provider redesign is out of scope” cannot demonstrate that order review works. Likewise, “create a database field” may be a task, but it does not explain what the customer should observe.

An unavailable delivery method is different from an excluded feature. It is an error state within the selected flow and needs a behavior decision. Moving it into “out of scope” would leave the customer path undefined. If it makes the story too large, split the work while keeping a usable path and agree on the new boundary explicitly.

Write a Given–When–Then version

Given–When–Then is useful when a condition depends on a specific state and action. The Cucumber Gherkin reference separates the starting context, the event, and an observable result. You can use that structure to clarify a conversation before anyone connects it to automated tests.

Scenario 1: review the current order

• Given the customer has the sample cart, a complete saved address, and standard delivery selected,
• When the customer opens order review,
• Then the summary shows the items, address, delivery method, $40 subtotal, $5 delivery, $4 tax, and $49 total.

Scenario 2: change delivery

• Given the customer is reviewing the sample order with standard delivery,
• When they choose express delivery and the price response succeeds,
• Then the summary shows $9 delivery and a $53 total before payment can continue.

Scenario 3: correct missing address information

• Given a required address field is missing,
• When the customer tries to continue from review,
• Then the field is identified, an address-edit action is available, and the customer remains before payment with the cart preserved.

Scenario 4: recover from a price-refresh failure

• Given the customer changed delivery and a new total is pending,
• When the price request fails,
• Then the page explains that the total could not be updated, offers retry, and prevents payment from continuing with the previous delivery price.

Each scenario answers one question. Avoid one long scenario that edits the cart, changes the address, applies a discount, and pays: if it fails, the relevant rule is harder to identify. Add another example when a different rule needs discussion, not merely to repeat the same condition with a new customer name.

Resolve open questions before implementation

Ask product whether the conditions express the desired scope, design how the states will be understood, engineering which dependencies can change the behavior, and QA how each result will be observed. A question such as “What happens when a saved address is no longer eligible?” needs a product decision, not a guessed test expectation.

Write an open question separately from an agreed criterion. For example: “If the previously selected delivery method becomes unavailable, do we preselect another method or require a new choice?” The answer changes both the interface and the test. Once the team decides, update the affected criterion and scenario together.

When new information changes the scope, record the decision instead of quietly deleting a difficult condition. If the team separates address editing into another story, the order-review story still needs a clear way to reach that behavior and return. Completing the acceptance criteria also leaves the team's Definition of Done in force.

Map the story and examples in Boardmix

Place the story at the top of a Boardmix board. Below it, arrange four areas: agreed criteria, worked examples, open questions, and exclusions. Give each criterion an ID, such as AC-2 for delivery changes, and place its scenario beside it. This makes it easier to see whether a rule has an example and whether a question could change an accepted condition.

Keep the shared Definition of Done in its own reference area rather than copying it into every scenario. After the discussion, the team can transfer the agreed criteria to its delivery record while using the board to retain the connections between the rule, example, and decision.

Open a Boardmix board to lay out the checkout story and its four scenarios. Start with the delivery-change example: it quickly reveals whether everyone means the same thing by “the total updates.”