Definition of Done: Agile Guide With Examples

Half the arguments in a sprint review come down to one word: done. The developer says the story is finished. The tester found no automated coverage. The product owner expected documentation. Everyone was right, because nobody agreed what "done" meant. A Definition of Done ends that argument before it starts.

This guide covers what a Definition of Done is, what belongs in one, how it differs from acceptance criteria, how to write one your team will actually use, and how to tell whether people are following it. There's a copy-paste example you can steal near the end.

What Is a Definition of Done?

A Definition of Done is a shared set of criteria that a piece of work must meet before the team agrees it's complete. It applies to every backlog item in the same way, so "done" means the same thing whether the story was a one-line fix or a two-week feature. It goes well beyond "the code runs." It covers whether the work was reviewed, tested, documented, and made ready to release.

In Scrum, this isn't optional folklore. The 2020 Scrum Guide lists the Definition of Done as one of three commitments, sitting alongside the Product Goal (committed to the Product Backlog) and the Sprint Goal (committed to the Sprint Backlog). The Definition of Done is the commitment attached to the Increment. The guide describes it as "a formal description of the state of the Increment when it meets the quality measures required for the product."

The consequence is what gives it teeth. If a backlog item doesn't meet the Definition of Done, it can't be released or even shown at the Sprint Review. It goes back to the Product Backlog for later. That's the line between work that ships and work that only looks finished.

"A story isn't done when it works on your machine. It's done when it meets the same quality bar as everything else your team ships."

What Should a Definition of Done Include?

There's no universal list, because the right bar depends on your product and risk tolerance. A Definition of Done for a payments system carries heavier checks than one for an internal dashboard. That said, most solid definitions group their checks into a handful of categories.

• Code: merged to the main branch, follows the team style guide, and carries no leftover debug logging or commented-out blocks.
• Review: reviewed and approved by at least one other engineer, with review comments resolved rather than ignored.
• Testing: automated tests written for new behaviour, the existing suite green in CI, and the change checked against its acceptance criteria.
• Documentation: public interfaces and config changes written up, and release notes updated when the change is user-facing.
• Operability: logging and metrics in place for new behaviour, and the change deployed to a staging environment and smoke-tested.

Notice that none of these mention story points, estimates, or how fast the work moved. A Definition of Done measures quality, not speed. Keep delivery-pace conversations in your sprint velocity discussion, where they belong, and keep the "is this good enough to ship?" question here.

Start lean. A Definition of Done isn't fixed forever. The healthiest approach is to begin with a small, honest list and add checks as the team learns where quality slips. A bar you actually meet every sprint beats an aspirational one you quietly ignore.

How Is a Definition of Done Different From Acceptance Criteria?

This is the most common point of confusion, and the answer comes down to scope. Acceptance criteria belong to one specific user story and describe what that feature must do. The Definition of Done applies to every story equally and describes the quality bar all of them share.

Put simply, acceptance criteria answer a product question and the Definition of Done answers an engineering question. Both have to be satisfied before a story is truly complete. A feature can pass every acceptance criterion and still fail the Definition of Done because nobody wrote tests for it.

"Acceptance criteria ask 'did we build the right thing?' Your Definition of Done asks 'did we build it well enough to ship?'"

How Do You Write a Good Definition of Done?

Write it as a team, in a room, in about an hour. A Definition of Done handed down from a manager or copied wholesale from a blog rarely survives contact with real work, because the people who have to meet it every day never bought into it. Here's a sequence that works.

1. Ask what "done" already means to each person. You'll get different answers, and that gap is exactly the problem you're solving. Write every answer on the board.
2. Group the answers into categories. Most cluster into code, review, testing, documentation, and operability. This becomes the skeleton of your list.
3. Cut anything you can't actually verify. "Code is clean" is a wish, not a check. "Linter passes with no warnings" is a check. Keep the ones you can point at.
4. Make each item pass or fail. A Definition of Done is a checklist, so every line needs a clear yes-or-no answer. Vague items get argued about, which defeats the purpose.
5. Agree it's the floor, not the ceiling. The Definition of Done is the minimum bar for every item. Individual stories can demand more through their acceptance criteria.

One more rule: keep it short. A Definition of Done that fills two pages is one nobody reads, and a bar nobody reads isn't a bar. Aim for something that fits on a single screen and lives where the team already works, pinned in the pull request template or the team wiki.

"The best Definition of Done is short enough to remember and strict enough to catch the corners you keep cutting."

What Does a Definition of Done Look Like? (Example)

Here's a Definition of Done you can copy, paste into your team wiki or pull request template, and adjust. It's written for a team shipping a web application from GitHub, so trim the checks that don't apply and add the ones your product needs.

## Definition of Done

### Code
- [ ] Merged to the main branch
- [ ] Follows the team style guide (linter passes, no warnings)
- [ ] No commented-out code or debug logging left behind

### Review
- [ ] Reviewed and approved by at least one other engineer
- [ ] All review comments resolved or turned into follow-up tickets

### Testing
- [ ] Automated tests written for the new behaviour
- [ ] Full test suite green in CI
- [ ] Manually verified against the story's acceptance criteria

### Documentation
- [ ] Public APIs and config changes documented
- [ ] Release notes updated if the change is user-facing

### Operability
- [ ] Feature flag added for anything risky
- [ ] Logging and metrics in place for new behaviour
- [ ] Deployed to staging and smoke-tested

This is a starting point, not a mandate. A team new to writing a Definition of Done might drop the operability section on day one and add it once the basics stick. A team on a regulated product might add checks for security review or audit logging. The list should describe your bar, not somebody else's.

How Do You Enforce a Definition of Done?

A Definition of Done only matters if the team meets it, and the honest truth is that most teams drift. Under deadline pressure, the testing check gets skipped, the documentation check becomes "later," and within a few sprints the list on the wiki no longer matches what actually ships. Enforcement is the difference between a real quality bar and a poster on the wall.

Start with automation, because a check a machine can enforce never gets skipped under pressure. Branch protection rules can require an approving review and a green CI run before a merge. A pull request template can put the checklist in front of every author. Your pull request checklist is the natural home for the code and review parts of your Definition of Done, and a good review culture is what makes the human checks worth having.

Automation covers the mechanical checks, but it can't tell you whether the habit is holding across the team over time. That's where your GitHub history earns its keep. If your Definition of Done says every change needs a review, the share of pull requests that merge without an approval tells you whether that's true. If it says tests must pass, your CI pass rate tells the same story. Read these at the team level and take them into a retro, the same way you'd read your DORA metrics.

You don't need a tool to start. Open your repository's merged pull requests, sort by most recent, and check twenty of them by hand against two or three lines of your Definition of Done: did each one get an approving review, and did CI pass before the merge? If most did, your bar is holding. If a third slipped through, you've found the check that needs a branch protection rule rather than a reminder in standup. Doing this by hand every sprint gets old fast, which is where automated tracking pays for itself, but it's a fine way to prove the problem is real before you spend anything.

Keep enforcement developmental. A Definition of Done that becomes ammunition in performance reviews teaches people to hide corners instead of raising them. When the data shows the bar slipping, treat it as a question for the group: is the check still worth having, is the team under too much pressure to meet it, or has the work changed? A bar the team keeps adjusting honestly is worth more than one it pretends to hold.

Done well, a Definition of Done quietly removes a whole class of arguments and a whole class of late surprises. It won't make anyone code faster, and it isn't meant to. It makes "done" mean something, so the next sprint review is about the product instead of the paperwork. For teams working on how to ship that product sooner, pair it with our guide on reducing PR cycle time.