# Definition of Done Examples for Shopify and Web Projects > Definition of done examples for Shopify and web projects: what belongs in the list, three levels of done, and how it differs from acceptance criteria. _Published: 2026-10-14 ยท CommerceCopilot_ ## "Done" means something different to everyone in the room Ask three people on a Shopify project whether a ticket is done and you can get three honest, incompatible answers. The developer says yes, the code works on their preview theme. The project lead says almost, it still needs review. The client says no, they have not seen it yet. None of them is wrong, because the project never wrote down what done means. A definition of done fixes that by turning a private feeling into a shared, checkable list, and it is one of the cheapest process documents an agency can adopt: you write it once and it settles the same argument on every ticket afterward. This post covers what a definition of done is, what belongs in one for web projects, and definition of done examples at the three levels where Shopify agency work actually gets judged: the ticket, the review link, and the launch. ## What a definition of done is The term comes from Scrum. The [2020 Scrum Guide](https://scrumguides.org/scrum-guide.html) defines the Definition of Done as "a formal description of the state of the Increment when it meets the quality measures required for the product," and treats it as a formal commitment attached to the Increment. The guide is strict about the consequence: work that does not meet the definition of done cannot be released or even presented at the sprint review. It goes back to the backlog. You do not need to run Scrum for the idea to pay off. Stripped of the ceremony, a definition of done is a quality bar that applies to every piece of work, agreed before the work starts. Its value is exactly that it is boring and universal: nobody negotiates it per ticket, nobody discovers it in review, and "I thought someone else was doing that" stops being a failure mode because the list says who checks what. ### Definition of done versus acceptance criteria These get conflated constantly, and the confusion causes real damage. Acceptance criteria are specific to one ticket: "the free shipping bar updates when the cart total changes" belongs on exactly one piece of work. The definition of done applies to all of them: code reviewed, tested on mobile, no console errors, works in the theme editor. A ticket is finished when it meets both its own criteria and the shared definition. Teams that merge the two end up copy-pasting "code reviewed and QA passed" into every ticket, where it buries the real per-ticket conditions in boilerplate until reviewers stop reading. Keep the shared bar in one document and the per-ticket conditions on the ticket. If your criteria need work too, we cover that side in [how to write acceptance criteria for Shopify tickets](/blog/writing-acceptance-criteria-shopify-tickets). ## What belongs in a definition of done for web projects Generic agile advice says things like "unit tests pass" and "documentation updated," which is fine as far as it goes but misses where Shopify and web projects actually fail. A useful definition of done for web projects names the checks that catch the failures your clients actually see. For agency Shopify work, that means the bar has to cover four layers: - **Code quality.** Reviewed by someone who did not write it, merged to the right branch, no errors in the browser console, no leftover debug output. On theme work, this includes not leaving dead settings or orphaned snippets behind. - **Behavior.** The ticket's acceptance criteria pass, on a real phone as well as desktop, with real catalog data rather than the friendly demo content the feature was built against. - **Merchant usability.** The client's team will live in the theme editor after handoff. A section that collapses when a merchant hides a block or writes a long heading is not done, even if it looks perfect with the settings the developer chose. - **No regressions.** Theme code is shared, so the definition should force a look beyond the ticket: the money path from product page to checkout still works, and the highest-traffic pages the ticket never touched still render. Two properties make a definition of done survive contact with deadlines. Every line must be checkable by someone other than the person who did the work, and the whole list must be short enough to actually run. A twenty-line definition is a wish list; teams skim it, and skimming is how the load-bearing line gets missed. ## Definition of done examples at three levels Agency work gets judged at three moments, and a single flat list serves none of them well. These definition of done examples are written to be adapted, not adopted verbatim: cross out what you do not do, and add the checks your last three postmortems wished existed. ### Example: done for a ticket The bar every individual piece of work must clear before it moves to the done column: - Acceptance criteria on the ticket all pass, checked by someone other than the developer. - Code reviewed and merged to the project's integration branch. - Checked on one real mobile device, not just a resized desktop window. - New sections and settings exercised in the theme editor, including hiding optional blocks. - No new browser console errors, and no debug output left in the code. - Ticket updated with anything the next person needs: settings added, decisions made, follow-ups filed. ### Example: done for a client review link Individually passing tickets can still combine into a broken page, so the review link has its own bar: - The full money path walked as a customer, from homepage to a completed test order. - Pages previewed with the client's real catalog: long titles, odd image ratios, small collections. - Empty and edge states checked: empty cart, empty search, 404, sold-out product. - Current Safari, Chrome, and Firefox on desktop, plus one real iOS and one real Android device. - Known issues listed in the message that sends the link, so the client discovers nothing by surprise. This level is where a definition of done and a QA process become the same thing; our [Shopify project QA checklist](/blog/shopify-project-qa-checklist) is effectively this list expanded to full depth. ### Example: done for launch - Everything above, run against the production theme. - Redirects in place for any changed URLs, and analytics and tracking pixels confirmed firing. - Apps reconnected and their widgets checked on the pages where they render. - Performance on the touched templates compared against pre-project numbers, not just eyeballed. - The client's team shown how to edit what was built, and a rollback path agreed before publishing, not after. ## How to keep a definition of done honest Most definitions of done fail the same way: they get written in a kickoff meeting, pasted into a wiki, and never looked at again. A few habits prevent that. **Give it an enforcement point.** A definition that nobody is required to check is decoration. The natural gate is the ticket's column move: nothing enters done until someone other than the author has walked the list. If that sounds slow, note what it replaces, which is the same checking done later by the client, with interest. **Change it when it fails.** When a bug reaches a client, ask which line of the definition should have caught it. If a line exists and was skipped, that is an enforcement problem. If no line exists, add one, and consider removing one that has never caught anything, so the list stays short enough to run. **Write it down before the project starts, with the client.** A definition of done is also an expectations document. When the client has agreed that done includes "tested on current browser versions" and does not include "pixel-identical to the Figma file at every viewport width," review conversations get noticeably calmer. The best time for that agreement is scoping, alongside the ticket structure itself; if your tickets do not yet have a shape a definition can attach to, start with [how to write development tickets a team can build from](/blog/how-to-write-development-tickets). **Keep it out of the tickets.** The definition lives in one place: the project wiki, the tracker's project description, wherever the team actually looks. The moment it gets copy-pasted into tickets it starts drifting, and three months later the project has four slightly different quality bars and no way to tell which one is current. ## Where CommerceCopilot fits A definition of done only works if every ticket arrives with the per-ticket half of the contract already written, because a shared quality bar cannot rescue a ticket whose acceptance criteria are "make the product page better." That upstream half is what CommerceCopilot's Business Analyst agent handles: it turns discovery calls, Slack threads, and briefs into structured tickets with acceptance criteria written as checkable lines, flagging open questions instead of inventing answers, with a human reviewing every draft before it reaches the tracker. The [brief-to-tickets walkthrough](/docs/your-first-brief-to-ticket-project) shows where that review sits. Downstream, the QA agent runs automated browser testing against those criteria on a [connected store](/docs/shopify) before a review link goes out. That turns the definition of done's most commonly skipped lines, the behavior checks, from a memory test into a gate that runs whether or not the team is busy that week. ## FAQ ### Is a definition of done the same as acceptance criteria? No. Acceptance criteria are conditions for one specific ticket; the definition of done is the quality bar every ticket must meet. A piece of work is finished when it satisfies both. Merging them produces tickets full of boilerplate and a quality bar nobody can find. ### Who writes the definition of done at an agency? The delivery team, not any single role, because every line is a commitment someone has to keep. In practice a project lead drafts it, developers and QA edit it, and the client sees the parts that shape their expectations. A definition imposed from above gets routed around within a sprint. ### How long should a definition of done be? Short enough to run on every ticket without skimming, which in practice means five to eight lines at the ticket level. Checks that only matter at review or launch belong at those levels instead. If the list has lines that have never caught a problem, cut them before adding new ones. ### Does a definition of done make sense outside Scrum? Yes. The term comes from Scrum, where the 2020 Scrum Guide treats it as a formal commitment, but the mechanism, a shared quality bar agreed before work starts, applies to any delivery process. Most Shopify agencies run something looser than Scrum, and a written definition of done is often the single most useful piece of Scrum to keep. --- Canonical page: https://www.commercecopilot.ai/blog/definition-of-done-shopify-projects