Definition of Done: Creating One That Works

The Definition of Done (DoD) is a shared agreement within the scrum team about what it means for any piece of work to be complete. It is not specific to any one story — it applies universally to everything the team ships. When a developer says a story is done, the DoD defines what that claim means.

Without a DoD, "done" means different things to different people. A developer might mean "the code works on my machine." A tester might mean "it passed all the manual tests." A product owner might mean "I can show it to a stakeholder." A DevOps engineer might mean "it is running in production." These are all reasonable definitions, and they are all different. The DoD eliminates that ambiguity by establishing one shared standard the whole team upholds.

The Scrum Guide describes the DoD as a formal description of the state of work when it meets the quality measures required by the product. That is not just a bureaucratic standard — it is the team's professional commitment to not shipping work that looks done but carries hidden risk, hidden debt, or hidden incompleteness.

This distinction is critical and frequently confused. Acceptance criteria are specific to a single user story. The DoD applies to all stories. Acceptance criteria define what this story needs to do. The DoD defines the quality bar that every story must clear regardless of what it does.

Think of it this way: acceptance criteria are the what, the DoD is the how-well. A story might have acceptance criteria like "Users can filter search results by date range" and "Results update within 500ms." Those are specific to that story. The DoD includes things like "all code is reviewed by at least one other developer" and "no new Sentry errors introduced in production" — standards that apply to that story and every other story the team ships.

A story can satisfy all of its acceptance criteria and still fail the DoD. Maybe the code was never reviewed. Maybe the feature has no automated tests. Maybe it is not deployed to the staging environment yet. The DoD catches these gaps that acceptance criteria were never designed to catch. Both are necessary; neither replaces the other.

The best DoD is the one your team will actually follow. That means it should be specific enough to be meaningful and short enough to be remembered. A DoD with forty items is a compliance exercise. A DoD with five to ten items is a quality commitment.

Start by asking the team: "What does a story need to have in place before any of us would be comfortable with it being called done?" Brainstorm freely, then consolidate. Look for items that almost everyone agrees on — those are your core DoD. Items that only one or two people care about might be team norms or personal preferences, not DoD material.

Write the DoD as a checklist, not prose. Each item should be unambiguously checkable. "Code quality is good" is not a DoD item — it is an aspiration. "Code passes ESLint with zero warnings" is a DoD item. "Tests cover the new functionality" is borderline — it needs more precision. "Unit tests cover all new business logic, and the overall coverage threshold has not decreased" is a DoD item.

While every team's DoD should be tailored to their context, some items appear repeatedly in well-functioning agile teams because they address the most common ways that "done" turns out not to be done.

Code review completed. No code merges without at least one reviewer who was not the author. This is a minimum bar for catching bugs, sharing knowledge, and maintaining code quality.

Automated tests written and passing. New functionality has tests. Existing tests are not broken. The specific type of tests (unit, integration, end-to-end) depends on what the story changed.

Deployed to staging or test environment. Code is not done on a developer's laptop. It needs to run in an environment that mirrors production before anyone can claim it is complete.

No new critical errors in production monitoring. After deployment to staging, check Sentry or your equivalent. If the story introduced unhandled exceptions, it is not done.

Product owner sign-off. For user-facing changes, the product owner has seen and approved the implementation. This is the moment acceptance criteria are formally validated.

Documentation updated. Relevant documentation — API docs, user guides, runbooks — reflects the change. This is the most commonly skipped DoD item and the one that creates the most long-term pain.

A DoD is not a permanent document. It should evolve as the team matures and as the product changes. The retrospective is the natural place to review it. Ask: "Did our DoD catch the things that went wrong last sprint? Are there gaps? Are there items we consistently fail to meet that we should either address or reconsider?"

Teams typically start with a lean DoD and add items as they encounter the problems that a more rigorous standard would have prevented. The first time the team ships a story that passes all acceptance criteria and breaks production because nobody checked the deployment pipeline, "verify deployment pipeline passes" gets added to the DoD. That is healthy evolution.

The direction should generally be toward higher standards over time, not lower. When a team is under pressure and starts discussing removing items from the DoD to go faster, that is a sign the team is borrowing against future quality — not actually moving faster. Push back on DoD reductions the same way you would push back on cutting tests or skipping code review.

A DoD that is too loose lets work through that is not genuinely complete. Stories pile up technical debt. Bugs get discovered after the sprint review. The team's definition of done diverges from the product owner's and the customer's. This is the more common failure mode.

A DoD that is too strict can paralyze a team. If the DoD requires every story to have end-to-end tests, full API documentation, and performance benchmarking, stories that should take two days take five. The team starts gaming the DoD — writing perfunctory tests, generating templated docs that contain no useful information — to check the boxes rather than meet the intent.

The calibration test: can the team consistently meet the DoD without heroic effort? If yes, the bar might be too low. If the team routinely fails to meet the DoD by the last day of the sprint, the bar might be too high for the team's current maturity. The goal is a DoD that stretches the team slightly — achievable with discipline, not achievable by cutting corners, not achievable only with overtime.

Most teams have a single DoD for all user stories, but different types of work sometimes warrant different standards. A bug fix might not require the same documentation update as a new feature. An infrastructure change might require additional items — load testing, rollback documentation — that are not relevant to UI work.

One pragmatic approach is a base DoD that applies to everything, with supplemental checklists for specific work types. The base DoD covers code review, tests, and deployment. The supplemental lists add context-specific requirements. This prevents the base DoD from becoming a sprawling document that tries to cover every possible scenario.

Whatever structure you choose, the critical thing is that the DoD is written down, visible to the whole team, and enforced consistently. A DoD that exists only in the scrum master's head is not a team agreement — it is a personal standard. Put it in your project wiki, your sprint board tool, or anywhere the team looks regularly. Review it in retrospectives. Treat it as a living document that reflects your team's current commitment to quality.