Definition of Done: Examples for Different Teams (2026 Guide)

Walk into most agile teams and ask “what does done mean?” and you will hear something like “when the task is finished.” Ask again, one level deeper — “finished to what standard? checked by whom? what has to be true?” — and the answers start to diverge. The developer thinks done is code that works locally; the tester thinks done is code that passes the test suite; the product owner thinks done is a feature a customer can actually use. When “done” means different things to different people, work gets marked complete far too early, and the gap shows up later as rework, broken releases, and trust damage. The definition of done (DoD) fixes this: it is a shared, written list of conditions that must all be true before any work is called complete. This guide explains what a definition of done is, why your team needs one, and — the part most guides skip — gives you ready-to-use DoD examples for software, marketing, content, design, QA, and operations teams, plus the habits that keep the DoD honest.

Quick Answer: What Is the Definition of Done?

The definition of done (DoD) is a formal, shared list of conditions that a product increment must meet for the team to consider it complete and ready for release or review. It answers the question “what has to be true before we call this done?” with a checklist that applies to every piece of work, so that developers, testers, and stakeholders all mean the same thing by “done.” The DoD is created by the team, displayed visibly, and updated regularly as the team improves.

The nuance: the DoD is not the same as acceptance criteria. Acceptance criteria belong to a single user story and describe that story’s expected behavior. The DoD is a higher-level, team-wide standard that applies to every increment — one team’s DoD might include “all tests pass and the code is reviewed,” and each story adds its own acceptance criteria on top of that.

Why Do Teams Need a Definition of Done?

Teams need a DoD because “done” is the most overloaded word in software and project work. Without a shared standard, each role fills the word with its own meaning, and the consequences are predictable: a feature marked “done” by a developer who never ran the test suite, a page marked “done” by a designer who never saw it on a real mobile device, a campaign marked “done” by a copywriter before legal reviewed it. Every one of those is a small trust break, and they accumulate into the big failure mode: rework at the end of the sprint, surprises at release, and stakeholders who stop trusting status reports.

A DoD changes the mechanics of completion. It forces the “done” conversation to be a checklist conversation instead of a vibe conversation. And it delivers three concrete benefits:

• Quality stays visible. The DoD keeps quality standards in front of the team at every story, instead of relying on a late-stage review to catch problems.
• Rework drops. When the standard is explicit, fewer items come back after being marked complete, because the standard was applied before the mark.
• Alignment improves. The whole team agrees on what done means before work starts, which removes the most common source of sprint-end conflict.

What Is the Difference Between Definition of Done and Definition of Ready?

The two concepts sit at opposite ends of the workflow and are constantly confused.

You use the DoR at backlog refinement to decide whether a story is ready to pull into a sprint. You use the DoD at the end of each story or increment to decide whether the work is complete. A team can have both, and most mature teams do. A common failure is treating the DoR as a substitute for the DoD — a story that is “ready” and “done” on the same lightweight standard is a story that was never properly tested or reviewed.

Who Creates the Definition of Done?

The whole team creates the DoD — not the project manager, not the product owner, not the scrum master alone. In Scrum practice, the DoD is a team agreement, and that is the point: a standard the developers, testers, and product owner each accept from the outside will not be honored; a standard they co-wrote becomes part of how the team works.

Practically, run a short workshop. Ask each role to answer one question: “what has to be true before you would call this work done?” The tester lists the tests that must pass. The developer lists code review and clean builds. The product owner lists the user-visible behavior. The designer lists the visual checks. Collect everything, merge the overlaps, and fight about the leftovers — the negotiation is where the value is, because it surfaces the different meanings of “done” that were silently co-existing. The result is a list of maybe six to twelve conditions that everyone accepts, and the team reviews it in retrospectives and revises it when the work or the standards change.

How Do You Write a Definition of Done?

Write the DoD with the whole team in a workshop, then follow these five steps to keep it usable:

1. List every role’s completion conditions. Each team member writes down what must be true for them to call work done. Do not judge yet; just collect.
2. Merge and de-duplicate. Combine overlapping items into single criteria. “Passes automated tests” and “no failing test cases” become one line.
3. Write each criterion as a verifiable condition. Every line must be checkable: “code reviewed by a second developer” is verifiable; “code looks good” is not. If you cannot check it, it is not a DoD criterion.
4. Agree on the list and display it. Get explicit agreement from the whole team, then put the DoD where it is seen daily — a sprint board, a team wiki, a checklist attached to every task.
5. Review and revise it in retrospectives. When the team discovers the standard is too loose (rework still happens) or too heavy (everything is slow), adjust it. The DoD is a living agreement, not a contract engraved in stone.

A good rule of thumb: start with the shortest list that honestly covers the work. A DoD with twenty items gets ignored; a DoD with eight gets applied. You can always add criteria later, and the retrospective is the place to do it.

What Is the Difference Between Definition of Done and Acceptance Criteria?

Acceptance criteria are the specific conditions a single user story must satisfy to be accepted — written by the product owner, often as Given/When/Then scenarios, and unique to that story. The definition of done is the team-wide standard that applies to every story and every increment. Think of it as two gates: the story passes its acceptance criteria (it does what the customer asked), and the increment passes the DoD (it meets the team’s quality bar). A story can pass acceptance criteria and still fail the DoD — the behavior is right, but the code was never reviewed or the tests are missing. That is exactly why both gates exist.

What Are Good Definition of Done Examples for Software Teams?

For a software development team, the DoD is where the concept is most mature, and a strong example looks like this:

• The code is written and merged into the main branch.
• A second developer has reviewed the code.
• All automated tests pass, including new tests for the changed behavior.
• No known critical or major bugs remain open.
• The feature works across the supported browsers and devices.
• Build and deployment to the staging environment succeed.
• User documentation and release notes are updated.
• The feature meets its acceptance criteria.

Notice two things. First, every line is verifiable — you can check each one. Second, the list is team-wide, not story-specific; the story’s acceptance criteria sit on top of it. For a mobile team you would add “passes the app-store review checklist”; for a data team you would add “schema migration reviewed and reversible”; for a web team you would add “performance budget met.” Adjust the list to the team’s reality, but keep the structure: verifiable, team-agreed, displayed, and enforced.

What Are Definition of Done Examples for Non-Software Teams?

The DoD is not a software-only concept. Any team that calls work complete needs a shared standard. Here are examples that teams outside development can adapt.

Marketing team

• The piece is approved by the campaign owner and, where needed, legal and brand review.
• All copy is checked against the brand voice and tone guide.
• Links are tested and analytics tags are verified.
• The asset is scheduled or published, and the tracking links are live.
• A short performance check-in is scheduled for the first week after launch.

Content and editorial team

• The piece is edited by a second person for structure, accuracy, and style.
• Facts and sources are verified and linked.
• SEO title, meta description, and internal links are set.
• Images are licensed, compressed, and have alt text.
• The article is scheduled or published, and the performance data is being collected.

Design team

• The design is reviewed against the component library and design system.
• Accessibility checks pass (color contrast, keyboard navigation, readable text sizes).
• The design is validated in desktop, tablet, and mobile breakpoints.
• The handoff files are organized and labeled for development.
• A stakeholder review has happened and feedback is resolved or logged.

QA and testing team

• The test plan for the release is complete and reviewed.
• All critical and major defects are closed or explicitly accepted by the product owner.
• Test evidence is attached to the release notes.
• Regression suites are run and green.
• A sign-off is recorded by the test lead.

Operations and support team

• Runbooks and support documentation are updated for the new process or system.
• Monitoring and alerting are configured for the new component.
• On-call staff are briefed on what changed.
• Rollback steps are documented and tested.
• A post-release review is scheduled.

The pattern is identical to software: verifiable conditions, agreed by the whole team, applied to every piece of work, and reviewed over time. Swap the tools and the vocabulary and the discipline is the same.

How Long Should a Definition of Done Be?

Short enough to be applied, long enough to protect quality. Most effective DoDs run from five to twelve criteria. Under five, the standard is probably too vague to catch the problems the team actually has. Over twelve, team members start skipping items and the DoD becomes decorative. If your list keeps growing past twelve, split it: keep the universal core in the DoD and move team-specific or release-specific items into the definition of ready or a release checklist. The test is always the same — can every team member recite the DoD and apply it to every piece of work without opening a document?

What Happens When You Have No Definition of Done?

Without a DoD, completion becomes a matter of individual judgment, and the cost shows up in three places. Rework: a story marked done by a developer who skipped the test suite comes back in the next sprint, burning time that was already “spent.” Unpredictable releases: the sprint board says everything is done, but the demo falls apart because “done” never included “works together on staging.” Trust erosion: when stakeholders hear “done” and get something that is not done, the status report loses meaning, and the team starts being asked for evidence on every item — which is slower than having had the standard in the first place.

The fix is not heroic — it is a half-day workshop to agree the list, a display where the team can see it, and a retrospective ritual that updates it. The difference between a team with a DoD and a team without one is not talent; it is the shared standard for what done means.

Common Mistakes

• Letting one person own the DoD. A DoD imposed by the project manager or product owner gets applied reluctantly. It must be a team agreement.
• Writing unverifiable criteria. “Code is clean” and “looks good” cannot be checked. Every criterion must have a yes/no answer.
• Mixing the DoD with acceptance criteria. Story-specific acceptance criteria that end up in the DoD bloat the list and make it less usable.
• Hiding the DoD in a wiki nobody visits. If the DoD is not visible at the point of work, it does not exist.
• Never updating it. A DoD written once and never revisited becomes either too loose (rework returns) or too heavy (everything slows down).
• Making it a checklist to game. When teams tick items without doing the work (“reviewed” with nobody having reviewed), the DoD becomes fiction — which is why visible evidence matters.
• Applying the DoD only to stories, not to increments. The DoD protects the release, not just the individual task. If the whole increment is not verified as one piece, integration problems appear at the demo.

Know This Before You Choose

• Does every role on the team have a different meaning of “done” right now — and can the team agree on one written list?
• Is every criterion on your draft DoD verifiable, or are some of them feelings wearing suits?
• Have you separated the team-wide DoD from story-specific acceptance criteria and the definition of ready?
• Is the DoD displayed where work happens, or does it live in a document nobody opens?
• Do you review the DoD in retrospectives, or was it written once and frozen?
• Can your project tool attach the DoD to tasks as a checklist, so completion means the checklist is complete?
• Are you starting with a short, honest list — or planning twenty items that will get ignored?

How Do You Enforce the Definition of Done in a Tool?

The DoD becomes real when the tool enforces it. A checklist attached to every task — the criteria the team agreed on — turns the poster on the wall into a working step in the workflow: the item cannot move to done until the boxes are checked. This is where the right tool matters. A platform that supports multi-level tasks, checklists, and quality control lets the team attach the DoD to each work item and make completion conditional on the checks. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. Doitify is an all-in-one platform for project management, team management, and goal achievement — you can define tasks and sub-tasks with checklists, assign owners and due dates, use quality control to review work before it is accepted, and keep sprint boards, backlogs, and reports in one workspace. For agile teams, that combination means the definition of done can be attached to the work itself rather than trusted to memory. Project management software that supports checklists and quality control makes the DoD an enforced workflow; for a small team on a short project, a shared checklist in a simple tool is enough.

Conclusion

The definition of done is one of the highest-leverage habits in modern project work. Bring the whole team together, write a shared list of verifiable conditions, display it where work happens, and review it in retrospectives. Separate it from the definition of ready and from story acceptance criteria, and keep it short enough to be applied honestly. For software, marketing, content, design, QA, or operations — the discipline is identical, only the criteria differ. And when your tool attaches the DoD to every task as a checklist, completion stops being a feeling and becomes a verified state. Explore Doitify Project Management to see checklists, quality control, and sprint boards supporting a real definition of done.