definition of done
Definition of done, or DoD, is a shared checklist of quality criteria that a team agrees every piece of work must satisfy before it counts as finished and can be released to users. The same bar applies to every feature, bug fix, and change, so “done” means the same thing across the whole team instead of being renegotiated item by item.
In Scrum, the definition of done is one of the framework’s formal commitments, attached to the increment a team produces each sprint. The Scrum Guide describes it as “a formal description of the state of the Increment when it meets the quality measures required for the product,” and the moment a backlog item meets that bar, a releasable increment exists. A real list is short and concrete:
Definition of Done
- Code reviewed and merged to main
- Unit and integration tests pass in CI
- Test coverage stays at or above 80 percent
- Public APIs and user-facing docs updated
- No high-severity static-analysis warnings
- Deployed and smoke-tested on staging
How It Shows Up in Practice
A Python developer meets the definition of done as the gate between “it works on my machine” and “the ticket is closed.” It usually lives in a CONTRIBUTING.md file, a pull request template, or a pinned checklist in the issue tracker, and automation enforces as much of it as habit does.
Continuous integration runs the test suite, a coverage tool fails the build below the agreed threshold, and a human reviewer signs off on the judgment calls before a merge.
Because the standard is identical for every item, the rule is deliberately all-or-nothing. An item satisfies the definition of done only when every box is checked, so a single unchecked item means the work is not done.
That all-or-nothing rule is the whole point. A feature that is “done except for the docs” is not done, and counting it as finished is how a backlog accumulates technical debt. Teams keep the list lean for the same reason, because a fifty-item checklist nobody reads protects nothing.
Definition of Done vs. Acceptance Criteria
The definition of done is easy to confuse with acceptance criteria, but the two work at different scopes. The definition of done is one global standard that applies to every item a team produces. Acceptance criteria are specific to a single user story and spell out what that one feature must do to satisfy its users, such as “a valid discount code reduces the cart total.”
A backlog item is complete only when it satisfies both gates: its own acceptance criteria and the team-wide definition of done.
The acceptance criteria prove the feature does the right thing, while the definition of done proves it was built to the team’s shared standard for shipping, down to the smoke test that has to pass on the way out. Those acceptance criteria are themselves often written as the plain-language scenarios of behavior-driven development.
Related Resources
Tutorial
Continuous Integration With Python: An Introduction
In this Python tutorial, you'll learn the core concepts behind Continuous Integration (CI) and why they are essential for modern software engineering teams. Find out how to how set up Continuous Integration for your Python project to automatically create environments, install dependencies, and run tests.
For additional information on related topics, take a look at the following resources:
- pytest Tutorial: Effective Python Testing (Tutorial)
- Continuous Integration and Deployment for Python With GitHub Actions (Tutorial)
- Build Robust Continuous Integration With Docker and Friends (Tutorial)
- Test-Driven Development With pytest (Course)
- Continuous Integration With Python (Course)
- Testing Your Code With pytest (Course)
- Effective Testing with Pytest (Quiz)
- Python Continuous Integration and Deployment Using GitHub Actions (Course)
- GitHub Actions for Python (Quiz)
By Martin Breuss • Updated June 5, 2026
