1 Overview
A Definition of Done is a shared agreement about what it means for a piece of work to be complete. It is not a checklist imposed from outside; it is a team's own explicit standard that turns vague notions of finished into something observable and testable. In Scrum, the Definition of Done applies to every Increment and is often refined as the team matures. In Kanban, a similar agreement is often encoded as part of the explicit policies that govern when a work item can move from one column to the next. The artifact matters because without it, done becomes a matter of opinion, and half-finished work can slip into release pipelines, demos, or customer hands.
The Definition of Done sits at the intersection of quality, predictability, and trust. It gives developers a clear target, gives reviewers a consistent basis for acceptance, and gives stakeholders a reliable signal about what is actually available. It also protects the team from the pressure to declare victory prematurely. When the Definition of Done is weak or implicit, work that looks complete on a board may still lack tests, documentation, integration, or operational readiness. The result is hidden rework, fragile releases, and a growing gap between what the team reports and what the product actually does. A strong Definition of Done does not guarantee perfect software, but it makes the cost of incompleteness visible before it ships.
2 The problem this method was built to solve
Software teams have long struggled with a simple but corrosive problem: work that appears finished is often not finished. A feature may pass a quick manual check but lack automated tests, error handling, accessibility support, or deployment scripts. A bug fix may resolve the reported symptom but leave related edge cases untouched. When teams lack a shared standard, each person applies their own private definition of done, and the gaps only surface later, usually at the worst possible time. This creates a pattern of half-finished work accumulating in the system, inflating estimates, and eroding trust between delivery teams and the people who depend on their output.
The Definition of Done was built to solve that ambiguity. It makes the completion criteria explicit before work begins, so that everyone shares the same expectations. It also addresses a deeper organizational problem: the temptation to treat progress as a matter of moving cards across a board. A card in a done column is not the same as a working, integrated, tested increment. By defining done in concrete terms, teams create a quality gate that is independent of optimism or schedule pressure. This does not eliminate the need for judgment, but it shifts the conversation from whether something is done to whether it meets the agreed standard. That shift is what prevents half-finished work from being counted, demonstrated, or shipped as though it were complete.
3 How one cycle runs, from ready to done
In a Scrum context, a cycle begins with a Sprint Planning session where the team selects Product Backlog items for the Sprint. Each selected item is discussed against the Definition of Done, and the team decomposes it into tasks in the Sprint Backlog. During the Sprint, developers pull tasks, collaborate, and update the board. The Daily Scrum is used to inspect progress toward the Sprint Goal and adapt the plan. Work is not considered complete when coding stops; it is complete only when every criterion in the Definition of Done has been satisfied. That might include code review, automated tests, integration, documentation, and any operational checks the team has agreed upon. At the end of the Sprint, the Increment is reviewed in the Sprint Review, and the Retrospective provides a chance to improve the Definition of Done itself.
In a Kanban context, the cycle is continuous rather than time-boxed. Work items are pulled from a ready queue into the first active column, then move across the board according to explicit policies. Each column transition has entry and exit criteria, and the Definition of Done is often expressed as the exit criteria for the final column. Work-in-progress limits constrain how many items can be in a given state, which exposes bottlenecks and encourages finishing before starting new work. A replenishment meeting may be used to refill the ready queue, and a service delivery review may examine flow metrics. The key difference is that Kanban does not wait for a Sprint boundary to declare done; an item is done when it satisfies the agreed policies and leaves the system. Both approaches rely on the same underlying discipline: work is not done until the shared standard says it is.
4 Roles and how they divide the work
Scrum defines three accountabilities: Product Owner, Scrum Master, and Developers. The Product Owner is responsible for maximizing the value of the product and for ordering the Product Backlog. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for helping the team and organization improve. Developers are accountable for creating the Increment and for meeting the Definition of Done. In practice, the Definition of Done is owned by the Developers, but it must be understood and respected by the Product Owner and other stakeholders. The Product Owner may negotiate scope, but cannot unilaterally lower the Definition of Done to make a Sprint look successful. The Scrum Master helps the team keep the standard visible and may facilitate conversations when external pressure threatens to weaken it.
Kanban does not prescribe roles, but mature Kanban implementations often define accountabilities around the service. A service request manager handles incoming requests and prioritization. A service delivery manager focuses on the flow of work and the health of the system. A flow manager may coach the team on limiting work in progress and improving cycle time. These roles are not mandatory, and many teams distribute the responsibilities differently. What matters is that someone is accountable for the policies that define done and for ensuring that work items actually meet them before they leave the system. In both Scrum and Kanban, the Definition of Done is a team agreement, not a manager's decree. When roles are clear, the division of work supports the standard; when roles are vague, the standard tends to erode under pressure.
5 Artifacts worth keeping
The most important artifact for this topic is the Definition of Done itself. It should be written down, visible to the team, and specific enough to be testable. A useful Definition of Done might include criteria such as code reviewed, automated tests passing, integration completed, documentation updated, and operational readiness confirmed. It should not be so long that it becomes bureaucratic, nor so short that it leaves obvious gaps. The Definition of Done is a living artifact; teams should revisit it in retrospectives or flow reviews and adjust it as their capabilities and context change. In Scrum, it applies to every Increment. In Kanban, it is often embedded in the explicit policies that govern column transitions.
Other artifacts support the Definition of Done rather than replace it. In Scrum, the Product Backlog and Sprint Backlog provide the work items and tasks, while the Increment is the tangible output that must meet the standard. In Kanban, the board, work items, and explicit policies make the flow of work visible. Service level expectations can clarify how long items should take, and cumulative flow diagrams can reveal whether work is piling up in a particular state. A checklist or template can help teams apply the Definition of Done consistently, but the artifact that matters most is the shared understanding behind it. If the written standard and the actual behavior diverge, the artifact is not doing its job. Keeping artifacts lightweight and current is more valuable than maintaining an impressive document that no one uses.
6 Where this method breaks down
A Definition of Done is not a silver bullet. It breaks down when it is treated as a formality rather than a commitment. If the team writes a standard but routinely bypasses it under deadline pressure, the artifact becomes theater. The same is true when the Definition of Done is copied from another team without adapting it to the local context. A standard that is too strict for the team's current capabilities can cause work to stall indefinitely, while a standard that is too loose provides little protection against half-finished work. The method also struggles when the organization rewards output over outcomes. If leaders celebrate the number of items marked done without checking whether they meet the agreed standard, the Definition of Done will be quietly ignored.
In Scrum, the Definition of Done can break down when the team does not control its own work. If external stakeholders add scope mid-Sprint or demand early demos of incomplete work, the standard is undermined. In Kanban, the risk is different: without explicit policies and work-in-progress limits, work can appear to flow while actually accumulating hidden debt. Teams may move items across columns without truly meeting the exit criteria, especially when the board is used as a reporting tool rather than a workflow tool. Another common failure is conflating the Definition of Done with acceptance criteria. Acceptance criteria are specific to a work item; the Definition of Done is a team-level quality standard that applies to all items. When the two are confused, teams may satisfy a narrow requirement while missing broader quality expectations. Honest use of a Definition of Done requires discipline, transparency, and a willingness to say that work is not done when it is not.
7 Frequently asked questions
Is a Definition of Done the same as acceptance criteria? No. Acceptance criteria describe what a specific work item must do to be accepted by the Product Owner or stakeholder. The Definition of Done describes the quality standard that every work item must meet before it can be considered complete. Acceptance criteria vary from item to item; the Definition of Done is consistent across the team. A work item can meet its acceptance criteria but still fail the Definition of Done if, for example, it lacks automated tests or documentation. Both are useful, but they serve different purposes.
Can a Definition of Done change over time? Yes, and it should. As a team improves its engineering practices, its Definition of Done can become more rigorous. Conversely, if the team discovers that a criterion is impractical or counterproductive, it can be adjusted. The important thing is that changes are deliberate and transparent, not a quiet lowering of the bar to accommodate schedule pressure. In Scrum, the Definition of Done is often revisited in the Retrospective. In Kanban, it can be reviewed as part of explicit policy updates.
What if different teams have different Definitions of Done? That is normal. A Definition of Done is context-specific. A team working on a mature product with strong automation may have a more demanding standard than a team building a prototype. The risk arises when multiple teams must integrate their work. In that case, they need a shared Definition of Done for the integrated Increment, even if their internal standards differ. Without that shared standard, integration becomes a source of late surprises and half-finished work. The goal is not uniformity for its own sake, but clarity about what done means wherever work is combined.