Bahasa Melayu

Definition of Done: Examples and How to Write One

Definition of done checklist with navy checkmarks and one final coral checkmark signaling work is complete

The definition of done (DoD) is one of those concepts that sounds obvious until your team ships something that broke in production, missed a review, or never got documented. Then it becomes urgent.

What is a definition of done (DoD)?

A definition of done is a shared, agreed-upon checklist of criteria that a work item must satisfy before the team considers it complete. Not "mostly done." Not "done on my machine." Actually done.

The DoD applies to every increment of work at the same level -- every user story, every sprint, every release. It's not written by one person and handed down. It's created by the team together, posted somewhere visible, and enforced consistently. When work meets every item on the list, it's done. When it doesn't, it isn't.

Key facts: definition of done

  • Teams with a clearly documented DoD ship 28% fewer defects than teams without one, according to research published in the Empirical Software Engineering journal (2018).
  • The 2023 State of Agile Report (digital.ai) found that inconsistent practices and unclear standards are among the top five reasons agile transformations fail -- the DoD directly addresses both.
  • A study by Capers Jones found that fixing a defect in production costs 10 to 100 times more than catching it during development; a DoD that includes testing and review requirements is one of the lowest-cost defect prevention tools available.

Definition of done vs. acceptance criteria

These two terms get mixed up constantly, and the confusion causes real problems. They're related but they cover different ground.

Dimension Definition of Done Acceptance criteria
Scope Applies to every work item at a given level (every story, every sprint) Specific to one user story or feature
Who sets it The whole team agrees and maintains it Product Owner or stakeholder defines it for that item
What it covers Quality standards, process steps, non-functional requirements Functional behavior the feature must demonstrate
Changes how often Rarely (only when the team evolves its standards) Every story or feature is different
Example "All code reviewed, tested, and merged to main" "User can reset password via email link within 60 seconds"

Acceptance criteria answers: does this feature do what it's supposed to do? The DoD answers: has the team done everything required to call this increment releasable?

A story can pass all its acceptance criteria and still fail the DoD if, say, the documentation wasn't updated or the code wasn't reviewed. Both gates need to pass.

Some teams also use a definition of ready (DoR) on the front end -- a checklist of conditions a work item must meet before the team pulls it into a sprint. The DoD closes the loop on the back end. Together, they create a quality boundary around the entire sprint cycle. See backlog refinement for how the DoR fits into sprint preparation.

Why a definition of done matters

Without a DoD, "done" means something different to every person on the team. A developer considers a feature done when the code compiles. The QA engineer considers it done when tests pass. The tech lead considers it done when it's code-reviewed. The product owner considers it done when it's deployed. None of them are wrong. But if they never align on a single standard, the team will keep shipping work that's partially done in ways nobody anticipated.

Here's what happens in practice. A team without a DoD:

  • Ships code that works locally but fails in staging because environment checks weren't part of anyone's mental checklist
  • Merges work that was "reviewed" by the person who wrote it
  • Accumulates documentation debt because nobody wrote it down as a requirement
  • Spends half the sprint retrospective discussing what "done" actually means for the stories they just finished

A team with a DoD:

  • Has a shared, non-negotiable standard that doesn't depend on individual interpretation
  • Catches gaps during the sprint, not after deployment
  • Reduces rework because everyone knows the exit criteria before starting
  • Moves faster because there are fewer surprises at sprint review

The DoD also protects the product backlog from false completion. When a story gets marked done without meeting all the criteria, the real work -- the fixes, the review, the documentation -- gets buried somewhere in the backlog and resurfaces later as unplanned work.

Levels of done

Most teams operate with three levels of done. Each level has its own checklist, and a higher-level checklist typically includes everything from the level below.

Story-level done

This is the checklist applied to individual user stories or tasks. It covers the specific work required to deliver one increment:

  • Code written and self-reviewed
  • Unit tests written and passing
  • Code reviewed by at least one other team member
  • Acceptance criteria met and verified
  • Feature branch merged to main (or the agreed integration branch)

Sprint-level done

This checklist applies to the entire sprint increment -- the sum of all stories completed in the sprint. It often adds integration and deployment criteria:

  • All story-level DoD items met for every story included
  • Integration tests passing against the full build
  • Deployed to staging environment
  • Sprint goal achieved or explicitly assessed
  • Release notes or change log updated

Release-level done

This covers everything required before the increment goes to production users. It's where compliance, performance, and sign-off criteria typically live:

  • End-to-end tests passing in a production-like environment
  • Performance benchmarks met (load time, error rate, etc.)
  • Security scan completed with no critical findings
  • Documentation updated and published
  • Stakeholder sign-off obtained
  • Rollback plan documented

Teams working in sprint planning should be clear about which level of done applies to each sprint's output. Not every sprint ends in a production release, but the team should know exactly where the bar is before they start.

Definition of done examples

Here are concrete DoD checklists for three common team types. These aren't templates to copy verbatim -- they're starting points. Your team's DoD should reflect your actual standards, tooling, and workflow.

Software development team (story level)

  • Code written and compiles without errors
  • Unit tests written for new logic, with at least 80% coverage on the changed files
  • Code reviewed and approved by at least one other developer
  • All automated tests passing in CI pipeline
  • No new linting errors introduced
  • Feature deployed to staging environment and smoke-tested
  • Acceptance criteria verified by the developer or QA
  • Any new APIs or configuration changes documented in the team wiki
  • Feature flag or toggle in place if the work isn't ready for full rollout

Marketing and content team (story level)

  • Content written to the agreed word count and tone guidelines
  • Reviewed by a second writer or editor for accuracy and brand voice
  • SEO checklist completed (title tag, meta description, target keyword in H1)
  • All internal links verified and working
  • Images optimized and alt text added
  • Scheduled or published in the CMS per the content calendar
  • Distribution tasks completed (social posts scheduled, newsletter inclusion confirmed)
  • Analytics tracking confirmed (UTM parameters, event tags in place)

Design team (story level)

  • Design matches approved brief or user story requirements
  • Reviewed by the lead designer and any relevant stakeholders
  • Accessibility guidelines checked (color contrast, type sizing, keyboard flow for interactive elements)
  • All states documented: default, hover, focus, error, empty, loading
  • Assets exported in required formats and uploaded to the shared design library
  • Handoff notes written for the development team
  • Any open feedback from review resolved or explicitly deferred with a reason

How to write a definition of done

Step 1: Gather the team

The DoD only works if everyone believes in it. That means creating it together -- developers, designers, QA, product owners, whoever does the work. A 60-minute workshop is usually enough to get a first version. Don't let the Scrum Master or team lead write it alone and present it for "approval." Co-creation is the point.

Step 2: List what completion actually requires

Start by asking the team: "Think of the last piece of work you shipped that came back with a problem. What step was skipped?" Work backward from failures to find the checklist items that matter. Then work forward: what does good look like when we ship? What would embarrass us if we forgot it?

Group items into categories: code quality, testing, documentation, deployment, review. This makes the DoD easier to scan during the sprint.

Step 3: Keep every item testable

Each DoD item should be verifiable -- either it's done or it isn't. "Code quality is good" is not a DoD item. "Code reviewed and approved by at least one team member other than the author" is. The test: can you point to evidence that this item was completed? If yes, it belongs on the DoD. If it requires judgment, turn it into a guideline or break it into more specific criteria.

Step 4: Agree and post it visibly

Once the team has a draft, get explicit agreement. Not "no objections" but actual buy-in. Post the DoD somewhere the whole team sees every day -- the sprint board, the team wiki, the channel description in Slack. It shouldn't be a document buried in a folder nobody opens. If the team can't see it, it won't be used.

Step 5: Review and evolve it

The DoD isn't permanent. It should get reviewed at the sprint retrospective whenever the team ships something that exposed a gap. When the team adds a new tool (say, an automated security scanner), add it to the DoD. When a checklist item becomes so automatic that nobody skips it, consider whether it still needs to be written down or whether it's now just a team habit.

A DoD that never changes is either perfect (unlikely) or being ignored (more likely).

Common mistakes

Making it too long. A 30-item DoD doesn't get used. Aim for 8 to 12 items that cover your real quality gaps, not an exhaustive ideal. If you can't recite the DoD from memory after a week, it's too long.

Writing it at the organizational level instead of the team level. A DoD handed down from leadership covers policy, not practice. Each team needs a DoD that reflects their actual workflow, tooling, and standards.

Treating it as aspirational. If the team can't realistically meet every DoD item in a normal sprint, the DoD is aspirational, not operational. Cut it back to what the team can actually commit to, then raise the bar incrementally as capacity and tooling improve.

Skipping it during crunch. "We'll skip the documentation this sprint because we're tight on time" is the moment the DoD stops meaning anything. Partial exceptions accumulate into consistent exceptions. If the DoD can be suspended under pressure, it was never a real standard.

Forgetting non-functional requirements. Functional behavior is covered by acceptance criteria. The DoD is where performance, security, accessibility, and documentation standards live. Teams that leave these out of the DoD ship features that work but degrade the system over time.

Frequently asked questions

Who owns the definition of done?

The team owns it collectively. The Product Owner can influence it (they care about releasability), and the Scrum Master can facilitate its creation and review. But in Scrum, the Developers are the ones who commit to meeting the DoD for every increment. Nobody can unilaterally change it mid-sprint.

What's the difference between a definition of done and a checklist?

A DoD is a type of checklist -- but one with a specific purpose and a specific contract behind it. A checklist is a tool. The DoD is an agreement that every increment must clear this bar before the team calls it done. The distinction matters because it implies shared ownership and consequences: work that doesn't meet the DoD doesn't get counted toward the sprint goal.

Does every team need a definition of done?

Yes, if the team ships work that other people depend on. The DoD is the mechanism that makes "done" mean the same thing to everyone. Teams without one either develop implicit standards (which aren't shared or enforced) or argue about done-ness at the worst possible moments, usually at the end of a sprint.

Can the definition of done be different for different types of work?

Yes, with caution. Many teams have a story-level DoD and a sprint-level DoD (as described in the levels section above). Some teams have slightly different criteria for bug fixes vs. new features. But be careful about fragmentation. The more exceptions and special cases the DoD has, the more cognitive load it creates and the less reliably it gets applied.

How does the definition of done relate to story points?

Story points estimate relative effort. The DoD defines quality standards. They're connected because the DoD should be factored into estimates -- if meeting the DoD for a story takes 3 extra hours, that time should be reflected in the story point estimate, not treated as overhead that gets skipped when the team is rushed. When teams underestimate stories because they're not accounting for DoD requirements, they end up in exactly the kind of crunch that leads to DoD shortcuts.

A well-crafted definition of done doesn't slow a team down. It removes the ambiguity that slows teams down. When everyone knows exactly what "done" means before they start, there are fewer surprises, fewer rework loops, and fewer arguments at sprint review. Start with something simple, enforce it consistently, and let it evolve as the team does.