"Done" is one of the most consequential words in software engineering, and its meaning varies substantially across teams, developers, and contexts. One developer considers a task done when the code is written. Another considers it done when it is reviewed. Another when it is deployed. Another when it is deployed and working in production. Another when it is deployed, working, and the stakeholder has confirmed it meets their expectation.
These are not trivially different interpretations. They produce materially different outcomes in terms of quality, predictability, and team trust. A team without a shared Definition of Done accumulates hidden work — the work between "I finished coding" and "this is actually complete" — that makes estimation impossible, creates deployment surprises, and erodes confidence in delivery dates.
The Definition of Done (DoD) is a shared checklist that specifies all the conditions that must be true before a piece of work can be considered complete. It is not a per-task checklist that varies with each story. It is a standing agreement that applies to every piece of work the team ships.
The Scrum Guide (Schwaber & Sutherland, 2020) defines the DoD as "a formal description of the state of the Increment when it meets the quality measures required for the product." The important words are "formal" and "required" — the DoD is not aspirational. It is the minimum.
The most common failure mode is a DoD that exists on paper but is not enforced in practice. Under deadline pressure, teams skip checklist items and rationalize it as a special case. The value of the DoD comes precisely from its unconditional nature: if the conditions are not met, the work is not done, regardless of the pressure to call it done.
A DoD for a backend feature in a professional engineering team typically includes:
Definition of Done — Engineering Team
A task is complete when ALL of the following are true:
Code quality
[ ] Code passes all automated tests (unit + integration)
[ ] No new linting errors introduced
[ ] Type-check passes with no new TypeScript errors
[ ] Code has been reviewed and approved by at least one other developer
Testing
[ ] Unit tests written for all new business logic functions
[ ] Integration tests written for all new API endpoints
[ ] Edge cases identified and either tested or explicitly documented as known limitations
[ ] All tests pass in CI
Security
[ ] New endpoints have authentication and authorization checks
[ ] Input validation is present on all new endpoints
[ ] No secrets, credentials, or PII are committed to the repository
Deployment
[ ] Feature works correctly in the staging environment
[ ] Database migrations are tested and reversible
[ ] Environment variables are documented in .env.example
Documentation
[ ] New API endpoints are documented in the OpenAPI spec
[ ] Significant architectural decisions are captured in an ADR if applicable
[ ] README is updated if setup instructions change
Acceptance
[ ] Acceptance criteria from the original task are met
[ ] No regressions in existing functionality
This is not a template to copy without adaptation. The right DoD for your team reflects the quality standards your team has agreed to, the testing infrastructure you have in place, and the deployment process you follow. The items above are representative of what a thoughtful senior developer would check before calling something done.
Many teams implicitly distinguish between "done" (the work is complete as far as the developer is concerned) and "done-done" (the work is complete as far as the product and the users are concerned). The gap between the two is the work that gets done after the feature is "finished" — the production bug, the edge case that was missed, the documentation that was forgotten, the performance problem that only appears at real scale.
The purpose of a rigorous DoD is to close that gap by surfacing the "done-done" work into the definition of done. If writing tests is part of the DoD, you cannot call something done without tests. If staging verification is part of the DoD, you cannot call something done until it works in staging. The hidden work becomes visible and required.
A DoD that is too aspirational will be ignored under pressure. A DoD that is too minimal will not meaningfully improve quality. The right calibration is to set the DoD at a level that reflects what the team can reliably achieve on every piece of work, then incrementally raise it as the team's practices improve.
A team that does not currently write tests should not adopt a DoD that requires 80% test coverage. They should adopt a DoD that requires unit tests for new business logic — a smaller requirement they can actually meet consistently. As testing becomes habitual, the requirement can be tightened. The DoD that is occasionally met is worse than no DoD, because it normalizes skipping checklist items.
Technical debt accumulates in the gap between "done" and "done-done." Every feature shipped without tests is a future debugging session. Every endpoint shipped without authorization is a future security audit finding. Every database migration shipped without a rollback plan is a future production incident.
The DoD is not bureaucracy. It is the explicit commitment to not create a specific class of technical debt. Teams that consistently meet a robust DoD have codebases that are genuinely maintainable — not because they have perfect code, but because the implicit work has been made explicit and required.
- Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/scrum-guide.html — Formal definition of Definition of Done, Increment quality.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press. — Quality practices and their relationship to delivery performance.
- Martin, R. C. (2008). Clean Code. Prentice Hall. — The boy scout rule, technical debt as a conscious decision.
- Fowler, M. (2019). "Technical Debt." https://martinfowler.com/bliki/TechnicalDebt.html — Definition, types, and when to pay it down.