What is the Definition of Done and how does it differ from acceptance?

The Definition of Done (DoD) is the formal description of the state that work must reach before it can be called finished: a written, shared list of quality conditions that applies to everything a development team delivers. The reference text is the 2020 Scrum Guide, the official definition of Scrum (a framework for developing a product in short, fixed-length cycles), which describes it as the state of the Increment, meaning the working piece of product built in a cycle, when it meets the quality measures required for the product. A typical DoD requires that a colleague review the code and that the automated tests pass. PMI, the international association of project managers, defines it instead in its Lexicon as a checklist of the criteria a deliverable must meet to be considered ready for customer use. In my reading, both make it the bar the team sets for itself, separate from the client's decision to accept what it receives.

See also: Scrum · A development framework of fixed-length cycles, three accountabilities and five events: useful only if the product owner really decides.

The team's commitment in the Scrum Guide

The Scrum Guide calls the DoD the commitment attached to the Increment. A work item that does not meet it cannot be released or even shown at the Sprint Review, the end-of-cycle meeting where the result is presented to stakeholders: it goes back to the Product Backlog, the ordered list of work to be done. If the organization has a company-wide DoD, every team follows it as a minimum; several teams on the same product share a single one, and the Developers, the people who build the product, are required to conform to it. According to the Guide, the DoD creates transparency: everyone shares the same understanding of which work has been completed.

DoD, acceptance criteria and contractual acceptance

The Scrum Guide never mentions acceptance criteria. PMI defines them as the conditions to be met before deliverables are accepted; the ISTQB glossary, from the international body that certifies software testers, defines them as the criteria a work product must satisfy to be accepted by the stakeholders. From these definitions I draw three levels that contracts often blur. The DoD is a single bar, the same for every deliverable, set by the Scrum Team, product owner included, or by the organization. Acceptance criteria belong to each deliverable and state what that deliverable must do. Contractual acceptance is the client's decision whether to accept, usually after user acceptance testing. A deliverable can therefore pass the DoD and still miss its own criteria.

An enterprise example

A manufacturer hires a supplier, working in two-week sprints, to build a dashboard that calculates supplier lead times every day. The statement of work, the document that describes what will be delivered, says only that every release will meet the supplier's Definition of Done. At every Sprint Review everything is marked done. After go-live, the purchasing department finds that the dashboard ignores partial deliveries and shows shorter lead times than the real ones. Nobody had written down how to count partial deliveries, or on which orders to check the count: the supplier met its DoD and the client has no measurable yardstick for a dispute. Adding that requirement now without revisiting price and schedule opens the door to scope creep, the expansion of scope without adjusting time and cost.

Why it matters for decision makers

A clause that treats every deliverable meeting the DoD as accepted hands the acceptance decision to the supplier's team. In Italian public procurement, acceptance remains the authority's own act: the verifica di conformità (conformity check), with methods and timing set in the capitolato, the contract's technical specification (article 116 of Legislative Decree 36/2023). A private contract benefits from the same separation: acceptance criteria for each deliverable, with the measurement method, in the document that describes the work; the supplier's DoD as an annex, read before signing, because it shows what quality the price includes, for example whether it covers security testing.

This entry is informational and does not constitute legal advice: for a specific contract, involve your legal counsel.