# How to Write Acceptance Criteria for Shopify Tickets > How to write acceptance criteria for Shopify tickets: a checkable format, real acceptance criteria examples, and the vague phrasing that causes rework. _Published: 2026-09-28 ยท CommerceCopilot_ ## Why "it works" is not acceptance criteria Every Shopify agency has shipped a ticket that was built exactly as written and still came back from the client. The developer did the work, the reviewer approved it, and the client opened the staging link and said "that's not what I meant." The gap is almost never effort. It's that nobody wrote down what done looks like, so three people each carried a slightly different version of it in their heads. Learning how to write acceptance criteria is the cheapest fix for that gap, because criteria get written once, before the build, when changing your mind costs nothing. The same ambiguity discovered in review costs a revision cycle. Discovered by the client, it costs a revision cycle plus a little trust. This post covers the format that holds up on Shopify work, with acceptance criteria examples for the ticket types agencies actually file. It assumes the ticket around the criteria is already in decent shape; if it isn't, start with [how to write development tickets a team can build from](/blog/how-to-write-development-tickets), since acceptance criteria can't rescue a ticket with no scope. ## What acceptance criteria are, and what they are not Acceptance criteria are the conditions one specific ticket must meet before it counts as complete. They are not the ticket's description. A description tells the developer what to build; criteria tell everyone, developer, reviewer, and client, how to check that the built thing is the right thing. A ticket needs both, and teams that merge them usually end up with neither. They are also not a definition of done. In Scrum terms, the definition of done is a quality bar the team applies to every piece of work (tests pass, code reviewed, deployed to staging), while acceptance criteria are specific to a single backlog item. The distinction matters in practice: "code reviewed and QA passed" belongs in your team's working agreement, written once. "Free shipping bar updates when the cart total changes" belongs on exactly one ticket. When definition-of-done items get copy-pasted into every ticket's criteria, the real per-ticket conditions drown in boilerplate and reviewers stop reading. The useful test for any single criterion: could someone who didn't build the feature, and wasn't in the client call, check it against the staging site and get the same answer as the developer? If checking it requires taste, context, or a follow-up question, it isn't a criterion yet. It's a hope. ## How to write acceptance criteria that survive review The mechanics are learnable. Four habits cover most of it. ### Write the observable outcome, not the implementation "Use the Cart API to update quantities" is an implementation note, and it might even be wrong by the time the developer looks at the theme. "Changing a quantity updates the line total and cart subtotal without a page reload" is an outcome anyone can verify in a browser. Keep implementation detail in the ticket's technical notes, where a developer can push back on it, and keep the criteria about what a user or reviewer can observe. ### One condition per line A criterion that reads "the filter updates results, shows the active filter count, and works on mobile" is three checks wearing one checkbox. When one of the three fails, the whole line is neither done nor not-done, and that ambiguity is exactly what criteria exist to remove. Split compound conditions. A ticket with nine short checkable lines reviews faster than one with three long debatable ones. ### Cover the states, not just the happy path Shopify storefronts have more states than a demo walkthrough shows: empty cart, sold-out variant, logged-in customer versus guest, a product missing the metafield the feature depends on, a discount already applied. Most "bugs" filed after launch are really states nobody wrote a criterion for, so nobody built or tested them. You don't need every state on every ticket. You need the ones where the right behavior is genuinely debatable, because those are the ones the developer will otherwise decide alone, silently. ### Pin numbers and boundaries "Loads fast" and "works on mobile" are the two most common unfalsifiable criteria in agency trackers. If speed matters, name the measurement and the threshold, and record the current value first so the comparison means something. If mobile matters, name the breakpoint or the behavior that changes. A boundary that isn't written down will be discovered in review, by disagreement. ## Checklist or Given-When-Then: pick per ticket, not per team Most Shopify tickets do fine with a plain checklist, one verifiable line per condition. The alternative is the Given-When-Then format, developed by Daniel Terhorst-North and Chris Matts as part of behavior-driven development: "Given a cart over $75, when the customer opens the cart drawer, then the free shipping bar shows the goal-met message." The same structure underpins the Gherkin syntax that tools like Cucumber execute as automated tests. Given-When-Then earns its extra verbosity when behavior depends heavily on starting state, which on Shopify work usually means anything involving cart logic, customer accounts, or discounts. For a static section with two states, a checklist says the same thing in half the lines. Teams that mandate one format for everything tend to produce ceremony on simple tickets and under-specified criteria on complex ones. Pick per ticket. ## Acceptance criteria examples from real Shopify tickets Weak versus rewritten, for three common jobs. **A free shipping progress bar in the cart drawer.** Weak: "Progress bar shows how close the customer is to free shipping." Rewritten: - Bar appears in the cart drawer when the subtotal is below the threshold, with the remaining amount stated in the store's currency. - Bar switches to the goal-met message when the subtotal meets or passes the threshold, without a page reload. - Bar is hidden entirely when the cart is empty. - Threshold amount is read from a theme setting, not hardcoded. **A "notify me when back in stock" button.** Weak: "Customers can sign up for restock alerts on sold-out products." Rewritten: - Button replaces the add-to-cart button only when the selected variant is out of stock; switching to an in-stock variant restores add-to-cart. - Submitting a valid email shows a confirmation message inline, without leaving the product page. - Submitting an invalid email shows an error and keeps the entered text. - Products with inventory tracking disabled never show the button. **A collection page filter.** Weak: "Filters work correctly on collection pages." Rewritten: - Selecting a filter updates the product grid and the result count without a full page reload. - Active filters display as removable pills above the grid. - A filter combination with zero results shows the empty-state message and a clear-all link, not a blank grid. - Filter state survives the browser back button from a product page. Notice what the rewrites share: each line names a state and an observable result, and none of them require the reviewer to have attended a meeting. These slot directly into the feature and enhancement structures in our [Shopify development ticket templates](/blog/shopify-development-ticket-templates), which cover the fields around the criteria. ## Where acceptance criteria go wrong - **Restating the title as a criterion.** "Size guide modal is added to the product page" verifies nothing the ticket's existence didn't already say. - **Criteria written after the build.** Written last, criteria describe whatever got built, which makes review a formality. Write them before estimation; they change the estimate. - **Testing the developer's honesty instead of the work.** "Code is clean and follows best practices" isn't checkable by a reviewer and insults everyone involved. Quality bars live in the definition of done. - **Client language pasted in raw.** "The page should feel more premium" is a real client goal and a useless criterion. The translation into observable changes is the whole job; skipping it just moves the argument to review. - **Twenty criteria on a two-hour ticket.** Criteria count should track ambiguity and risk, not ticket ceremony. Over-specified small tickets train the team to skim, and skimming is how the one load-bearing line gets missed. ## Writing criteria at agency volume One well-written ticket is a craft problem. Forty tickets a week across six client projects is a throughput problem, and it's where criteria quality actually breaks down: the senior person who writes sharp criteria becomes the bottleneck, and under deadline pressure the lines get vaguer exactly when the project can least afford it. This translation step, client language in, checkable conditions out, is the core of what CommerceCopilot's Business Analyst agent does. It drafts tickets from call transcripts, Slack threads, and briefs with acceptance criteria already structured as verifiable lines, and when the source material doesn't say what should happen in a given state, it flags the open question instead of inventing an answer. A human still reviews every draft before it reaches the tracker; the [brief-to-tickets walkthrough](/docs/your-first-brief-to-ticket-project) shows where that review step sits. The criteria also feed directly into QA, since a checkable line is a test case waiting to be run, which is the link our [Shopify project QA checklist](/blog/shopify-project-qa-checklist) builds on. ## FAQ ### How many acceptance criteria should a ticket have? As many as there are genuinely debatable conditions, and no more. Small tickets often need two or three lines; a feature with cart logic and multiple states might need ten. If you can't imagine two reasonable people disagreeing about a line, it probably doesn't need to be written. ### Who should write acceptance criteria? Whoever can translate client intent into checkable conditions, which usually means a business analyst or whoever plays that role. Developers should review criteria before estimating, because they'll spot the missing states, but a developer writing criteria for their own ticket mid-sprint tends to describe what they already plan to build. ### Should acceptance criteria be written in Given-When-Then format? Only when starting state drives the behavior, which on Shopify work typically means carts, accounts, and discounts. For simpler tickets a plain checklist is faster to write and easier to review. The format is a tool, not a policy. ### Are acceptance criteria the same as test cases? They're adjacent, not identical. A criterion states a condition that must hold; a test case adds the concrete steps and data to verify it. Good criteria convert to test cases with almost no rework, which is a reasonable quality check: if QA can't turn a criterion into a test, it was too vague to build from too. --- Canonical page: https://www.commercecopilot.ai/fr/blog/writing-acceptance-criteria-shopify-tickets