Acceptance criteria are the list of conditions that must be true for you to say "yes, this is what I asked for". They are written before the work starts, in plain language, and each one can be checked with a simple yes or no. "The discount code field accepts codes in upper or lower case" is an acceptance criterion. "The checkout feels smooth" is not.

They concern anyone who asks someone else to build something. That includes a founder briefing a developer, a brand hiring an agency for a store redesign, and a product team inside a software company. If you ever paid for work and then argued about whether it was finished, acceptance criteria are the tool that would have prevented that argument.

What are acceptance criteria?

Acceptance criteria are a set of precise, testable statements attached to a unit of work, usually a user story or a feature. They describe the expected behavior from the user's point of view: what goes in, what comes out, and what happens in the tricky cases. When every criterion passes, the work is accepted. If one fails, the work goes back.

They are not a technical specification. They say what must happen, not how the developer should code it. They are also not the same as the "definition of done". The definition of done is a general checklist that applies to every task in a team, such as "code reviewed, tests written, deployed to staging". Acceptance criteria are specific to one piece of work.

Related vocabulary:

  • User story: a one-line need, like "as a customer, I want to apply a discount code so that I pay less".
  • Given, when, then: a popular format for criteria. Given a starting situation, when the user does something, then a result follows.
  • Edge case: an unusual situation the work must still handle, like an expired code or an empty cart.
  • User acceptance testing: the moment when the person who asked for the work checks it against the criteria.

Why it matters

Unclear requests are the most common reason software projects go over budget. The developer builds what they understood, you expected something else, and the gap is paid for in extra days.

Picture a brand that sells supplements and processes 800 orders a month. It hires a freelancer for 6,000 dollars to add a "subscribe and save" option to its custom store. The brief says "customers can subscribe for a discount". The freelancer delivers a checkbox that applies 10% off the first order. The brand expected 10% off every recurring order, a way for customers to skip a month and a reminder email three days before each charge. Those three extra items take another eight days of work at 450 dollars a day, so 3,600 dollars more, and the launch slips by two weeks.

Written as acceptance criteria before the start, those expectations would have been in the quote. The freelancer could have priced them, or pointed out that some were complex, and the brand could have decided to launch without the skip option. The total cost might have been the same, but it would have been a decision instead of a surprise.

How it works

Writing good acceptance criteria follows a simple routine:

  • Start from the user story. Write who the user is, what they want and why, in one sentence.
  • List the main path. Describe what happens when everything goes right, step by step, in observable terms.
  • Add the edge cases. Ask "what if" questions: what if the code is expired, the product is out of stock, the customer is on a phone, the payment fails.
  • Make each criterion testable. Replace words like "fast", "nice" or "intuitive" with something you can check, such as "the page shows the new total without reloading".
  • Keep them independent. Each criterion should be checkable on its own, so a failure points to one specific problem.
  • Review them together. Read the list with the person who will build it, before work starts. Their questions reveal gaps.
  • Test against them at delivery. Go through the list one by one, and write down which pass and which fail.

A criterion in the "given, when, then" style reads like this: given a customer has a product at 40 dollars in the cart, when they enter the code SPRING15, then the cart total shows 34 dollars and the code appears under the order summary.

Benchmarks and examples

There is no fixed number, but these ranges are typical:

  • Three to eight criteria per story is a common range. Fewer usually means edge cases are missing. More than ten often means the story is too big and should be split.
  • A small store project, like a redesign of the product page, might have 30 to 60 criteria across all its stories.
  • Edge cases often make up a third to half of the list. They are where most bugs hide.

Examples from real seller situations:

  • Discount code: a code that expired yesterday shows the message "This code has expired" and the total does not change.
  • Stock: when the last unit of a variant is sold, that variant shows "Sold out" on the product page and cannot be added to the cart.
  • Digital delivery: within one minute after a successful payment, the buyer receives an email with a working download link.
  • Checkout on mobile: on a screen 375 pixels wide, the Pay button is visible without horizontal scrolling.

Common mistakes

  • Writing opinions instead of conditions. "The design should be modern" cannot be tested. Point to a mockup or a measurable detail instead.
  • Forgetting the failure paths. Most criteria lists cover the happy path only. Declined cards, empty fields and slow connections are where customers get stuck.
  • Dictating the technical solution. "Use a popup library" constrains the developer without telling them the goal. Describe the result.
  • Adding criteria after the work starts. New criteria mid-project are new scope. They are legitimate, but they should be priced and scheduled, not slipped in.
  • Never testing against them. A list nobody checks at delivery is decoration. Walk through it every time.

Best practices

  • Write them before asking for a quote. A developer can price a clear list far more accurately than a paragraph of intentions.
  • Use real numbers and examples. "A 40 dollar product with a 15% code shows 34 dollars" leaves no room for interpretation.
  • Include one criterion per edge case you fear. If a problem has cost you orders before, write it down so it is tested.
  • Agree on who tests. Decide whether you, a product owner or a tester checks the criteria, and when.
  • Keep them in the same place as the task. Attach them to the ticket or the brief, so the list and the work never drift apart.
  • Split large stories. If a story needs fifteen criteria, break it into two or three smaller stories that can ship separately.

In Roctify

On Roctify, the core commerce behaviors you would otherwise write criteria for, such as cart, one-page checkout, discount codes, stock updated across every channel, taxes and automatic delivery of digital products, are already built and maintained by the Roctify team as part of the platform. You test them by using your own store, not by commissioning and accepting them.

Acceptance criteria still help you when you set things up. Before a launch, write a short list for your own store and check it, for example: a test order with a discount code shows the right total, a digital product arrives by email after payment, the storefront reads well on a phone. It is the same discipline, applied to configuration instead of code, and it catches mistakes before customers do. For custom integrations on the Enterprise plan, clear criteria make the scope easier to agree on.

FAQ

Who writes acceptance criteria?

Usually the person who owns the need, like a founder, a product owner or a client, writes a first version. The developer and tester then review it and add the cases they spot. The best lists come from that conversation rather than from one person alone.

What is the difference between acceptance criteria and a definition of done?

Acceptance criteria are specific to one feature and describe its behavior. The definition of done is a general checklist that applies to every task, such as code review and testing. A piece of work needs both to be finished.

Can acceptance criteria change during a project?

Yes, but a change is a change of scope. Discuss it openly, agree on its effect on cost and timing, and update the written list. Silent changes are how disputes start.