Definition Of Done As A Contract

Most Definitions of Done are a bullet list on a wiki page, written during a team's second week, never revised, and consulted by nobody. Code reviewed. Unit tests written. Merged to main. Acceptance criteria met. It is a reasonable description of a developer's personal finishing routine and it is almost entirely worthless as an organisational instrument, because it says nothing about whether the thing could actually be given to a customer.

The gap between that list and a genuine standard is where most delivery risk accumulates. An increment that satisfies the wiki page but has not been performance tested, has no alerting, fails on a screen reader, and has not had its data retention considered is not finished. It is finished-looking, and the remaining work has not disappeared — it has been moved somewhere less visible and more expensive, usually into a hardening period, a pre-release scramble or a production incident.

The Definition of Done is the commitment attached to the Increment. Its job is to make the word "done" mean the same thing to the developer, the Product Owner, the security function, the auditor and the customer. That is a contract, not a checklist, and it should be treated with the seriousness that word implies.

What it actually is

Three properties distinguish a real Definition of Done from a team habit.

It is a statement about releasability, not about effort. The test is not "have we finished working on it" but "could this go to a customer today without further work by anyone". If the honest answer requires a subsequent activity by a separate team — a regression pass, a security review, a manual deployment runbook — then the Definition of Done does not yet describe done.

It is binary and inspectable. Every item is either satisfied or not, by observation rather than by assertion. "Code is of good quality" is not an item. "Static analysis passes with no new critical findings" is. If two competent people can disagree about whether an item is met, it needs rewriting.

It is the organisation's floor, not the team's preference. Where the organisation defines a standard, teams inherit it. They may add to it. They may not subtract from it. This asymmetry is the whole mechanism — it lets a large product hold a consistent quality bar while allowing individual teams to be stricter where their domain requires.

Where no organisational standard exists, the team must create one, and the resulting fragmentation is usually the first thing worth fixing in a multi-team product.

Why "contract" is the right word

A contract binds more than one party, and this one binds three.

The team undertakes that anything declared done meets the standard. In exchange, the team gets something valuable: the right to refuse. When a Product Owner or a delivery manager asks to ship something that has not met the standard, the answer is not a negotiation about professional judgement under time pressure — it is a reference to an agreement made calmly in advance by people who were not in a crisis. That is a substantial protection and teams undervalue it badly.

The Product Owner undertakes to accept the standard as the cost of the work, which means accepting that less scope fits in a sprint than a lower bar would allow. In exchange, the Product Owner receives an increment they can actually release on their own authority, which is the thing that makes the role meaningful.

The organisation sets the floor and undertakes to fund it. Accessibility conformance, security scanning, performance budgets and audit evidence are not free, and an organisation that demands them while planning as though they cost nothing is asking the team to resolve that contradiction quietly. It always gets resolved the same way.

What belongs in it

Most definitions cover the functional and stop. The expensive omissions are elsewhere.

Non-functional behaviour. A performance budget the change must not breach, stated as a number against a specific journey. Resource limits. Behaviour under a dependency failure. These are the requirements that do not appear in acceptance criteria and that are discovered, if they are discovered at all, in production.

Security. Dependency vulnerability scanning with an agreed threshold. No secrets in source. Authorisation verified for any new endpoint. A threat modelling conversation for anything that changes the external attack surface. These items reliably get skipped when they live in a separate review process and reliably get done when they run in the pipeline.

Accessibility. Conformance to the level your organisation has committed to — typically a WCAG level for public-facing services, and a legal requirement in many jurisdictions for public sector work. Automated checks catch a meaningful share of issues and should be in the pipeline; keyboard navigation and screen reader verification need a human and should be named as a step. Accessibility treated as a late audit is the most reliably expensive form of rework in front-end delivery, because the defects are usually structural.

Compliance and auditability. Whatever your regime requires as evidence: change records, segregation of duties, approval trails, data classification, retention and deletion for any new field holding personal data. As agile in regulated environments argues, most of this evidence can be produced automatically by the pipeline, and embedding it in the Definition of Done is what makes continuous delivery defensible to an auditor.

Operability. Logging, metrics and alerting for the new behaviour. A runbook entry if the change introduces a new failure mode. Feature flag defaults and rollback path. A change that cannot be observed in production is a change you will learn about from a customer.

Documentation that someone reads. The API reference, the architecture decision record, the operational note. The test is whether a named audience consumes it.

Weak formulation	Enforceable formulation
Tested	Automated tests at the appropriate level pass in CI; no manual regression required to release
Secure	No new critical or high findings from dependency and static scanning; authorisation verified on new endpoints
Performant	The affected journey stays within its stated latency budget under the standard load profile
Accessible	Automated checks pass; keyboard and screen reader path verified for new interactive components
Documented	API reference updated; an ADR exists for any decision that is expensive to reverse
Deployed	Released to production behind a flag, observable, with a tested rollback

Undone work is debt with an unstated interest rate

LeSS gives a useful name to the gap between what a team calls done and what is genuinely releasable: undone work. It is the testing that will have to happen later, the integration not yet performed, the security review still to be scheduled, the accessibility fixes that will be raised after an audit.

Undone work has two properties that make it dangerous. It is invisible on the board, because the items it attaches to have been marked complete. And it accumulates non-linearly, because the cost of integrating and verifying a batch of deferred work grows faster than the batch does. A hardening sprint is not a phase of the process; it is the bill for undone work arriving all at once, and its unpredictable length is the single most common cause of missed release dates in organisations that otherwise look well-run.

The Definition of Done is the instrument that prevents this. Every item you remove from it to go faster this sprint becomes undone work with a repayment date you have not scheduled and an amount you have not estimated.

The relationship with technical debt

The two concepts are frequently confused and the distinction is worth being precise about, because it changes how you talk to finance.

Technical debt, used properly, describes a deliberate choice: a simpler design taken now, in full knowledge that it will cost more to change later, because the value of shipping sooner exceeds that future cost. It is a financing decision and it can be a good one. This is the framing developed in technical debt as an economic decision.

Work that falls below the Definition of Done is not debt. It is an unpaid obligation that has not been declared. Nobody weighed the cost, nobody recorded the decision, and the amount owed is unknown. Debt has a rate and a term; this has neither.

The practical consequence is that the Definition of Done draws the boundary between the two. Above the line, a team can make deliberate architectural trade-offs and record them. Below the line, there is no trade-off being made — there is only decay that will present itself later as an incident, an audit finding or a rewrite.

Why per-team definitions fragment a product

In a single-team product, a team-level Definition of Done is fine. In a multi-team product it is corrosive, for four reasons.

Customers experience the product, not the team. A user encountering an inaccessible screen does not care which team built it. The perceived quality of the whole is set by the weakest contributor, which means the effective standard of a product with six teams is the lowest of the six definitions.

Integration cost falls on whoever is strictest. If one team ships without contract tests and another has them, the second team absorbs the breakage. Over time this produces a rational drift downward, because being strict is punished.

Release decisions become impossible to make. If "done" means different things across teams, nobody can answer whether the release is ready without inspecting each contribution individually, which is exactly the coordination overhead that dependency mathematics warns about.

The organisation cannot make a quality commitment. Security and compliance functions need to state that the product meets a standard. They cannot do so on the basis of six different standards, so they will impose a central gate instead — and a central gate is a queue, which slows everything down and is how you arrive at water-scrum-fall by a route that looks entirely reasonable at each step.

The correct structure is one product-level Definition of Done that every team inherits as a minimum, plus team-level extensions where a domain demands more. The payments team may require additional controls. Nobody may require less.

How to evolve it

The Definition of Done should ratchet in one direction, slowly, and each addition should be automated where possible.

Add roughly one item per quarter. Enough to raise the bar visibly, not enough to stall delivery. Announce it in advance with a date.

Automate before mandating. An item enforced by a pipeline is met every time. An item enforced by memory and a checklist is met when people are not busy, which is exactly when it matters least. Where an item cannot be automated, name the person or role accountable for the check.

Retire items that have become structural. If your build physically cannot produce an artefact without passing the tests, the checklist item is noise. Remove it and keep the list short enough to be read.

Review it after incidents. Every serious production incident should end with one explicit question: would a change to the Definition of Done have prevented this? Often the answer is no, and it should be recorded as no. When it is yes, that is the best evidence you will ever get for what belongs in the standard.

Never let it be lowered by an individual under pressure. Changes go through the same forum that set it, with a written rationale. That is deliberately heavyweight: this is the one artefact standing between delivery pressure and the organisation's risk position.

What to do on Monday

Find your current Definition of Done. If you cannot find it in ten minutes, that is the finding, and the remedy is a forty-five minute session with the team to write down what "done" currently means in practice — not what it should mean.

Then take the last three things the team marked done and test each one against a single question: could this have gone to a customer that afternoon, with no further work by anyone in the organisation? Write down every activity that would still have been required. That list is your undone work, and it is almost certainly longer than anyone expects.

Finally, if you have more than one team on the same product, put their definitions side by side on one page. The differences will be substantial and nobody will have seen them together before. Agree a single floor, publish the gaps as funded work, and set a date. That exercise takes an afternoon and it is the most direct route to being able to say, truthfully, that your product meets a standard.