14 minute read
- The minimum Definition of Done belongs to the people accountable for the business and its customers, with engineering informing it but not owning it.
- Whoever owns the Definition of Done decides what happens when deadlines conflict with it, so only one accountable owner should hold it, not shared ownership with engineering. see why — jump to the section that argues this
- The Definition of Done is a minimum state that protects the business and its customers, not a maximum and never the whole of product quality. see why — jump to the section that argues this
- This week, test your current Definition of Done against the nine questions given, and treat every “yes” to questions 1–8 as something you must fix.
- Move ownership of the minimum Definition of Done to the accountable business leaders, with engineering advising but not co‑owning, and make that ownership explicit.
- Require any decision to ship below the Definition of Done to have a written C‑suite signature recorded as explicit risk against the investment’s value on the company’s books.
The minimum Definition of Done exists to protect the business and its customers, so it belongs to the people accountable for them. Engineering informs it, and engineering should not have to set it: when it does, the business has given up a decision that is its own. Name the person who would answer to the board or the regulator if work shipped below it harmed a customer. If you cannot, nobody owns it yet.
In the organisations I work with, the Definition of Done is usually left to engineering. It ends up describing what engineering can control (tests written, code reviewed, a pipeline passed) rather than what the business is exposed to. A leader reading it cannot tell whether the work protects customer data, meets accessibility duties, or keeps the company on the right side of its regulators. I have argued before that the Definition of Done should come from the business and be objective.
Whoever owns the Definition of Done decides what happens when a deadline arrives
When engineering owns the Definition of Done, I see three faults again and again. Scope gets in, as “meets acceptance criteria”. Numbers stand in for quality, as “80% code coverage”. Handoffs replace states, as “code reviewed” and “QA signed off”. Each of these is something engineering can tick without anyone accountable for the business looking at it.
The more serious fault is what happens under pressure. A deadline arrives, the work is not ready, and somebody has to decide whether to ship. If the bar belongs to engineering, the pressure flows to engineering, and engineering is rarely in a position to refuse the people who set its deadlines. In my experience, the bar gets waived quietly once, and after that waivers become routine.
My view is that whoever owns the bar decides what happens when it gets in the way. When the people accountable for the business own it, lowering it means one of them putting a name to that decision. That moves the decision to the people who carry the consequence.
Many readers will hold a different model: engineering and the business own it jointly, with business sign-off. I think shared ownership leaves the bar negotiable between two owners at exactly the moment of pressure, and each can assume the other is holding it. One accountable owner, with engineering advising, does not have that gap.
Engineers know how to achieve quality and how to show it. Knowing how is not the same as being accountable for the exposure. Leaders set the minimum; engineering advises on it and meets it.
The Definition of Done is the minimum that protects the business and its customers
What does the Definition of Done protect? In the organisations I work with, the answer usually includes security, privacy, accessibility, and legal and regulatory duties. The list is not complete. Each item is something the business answers for when it goes wrong, and each one is a duty to customers as much as to the company.
It is a minimum, not a maximum. Products and teams go above it all the time, and they should. It is also never the whole of quality: a product can meet the Definition of Done and still be clumsy, slow, or unloved.
For an organisation whose work is not yet live in production when it is called Done, I suggest something like this:
Integrated into the main build, releasable, meeting our quality and security standards, and instrumented with telemetry that will support or weaken the hypothesis the work started from.
Every phrase in that statement describes a condition of the work, with evidence attached to the work, that protects something the business cares about. None of it says how the team got there.
Shipping work that is not Done harms the business and its customers
Shipping work that has not reached the Definition of Done is a false value proposition: it looks like delivery, and I hold that it harms rather than helps. Low-quality work costs time, defects and money, and the studies below put figures on it.
Tornhill and Borg found that low-quality code “contains 15 times more defects”, that issues took about 124% longer to resolve, and that maximum cycle times were about 9 times longer, though the authors work for CodeScene and used that vendor’s own measure of code quality [1]. Besker, Martini and Bosch reported that developers “waste, on average, 23% of their time due to TD” (technical debt), a figure the developers in the study reported themselves [2]. CISQ estimated the cost of poor software quality in the US at “at least $2.41 trillion”, with technical debt at about $1.52 trillion, a macro estimate that is not peer-reviewed [3]. DORA’s guidance states that “speed and stability are not tradeoffs”, which undercuts the idea that shipping below the minimum buys speed, though the finding comes from survey data and is correlational rather than causal [4].
One widely repeated claim does not survive scrutiny. Menzies and colleagues found “no evidence for the delayed issue effect” across 171 projects, which contradicts the popular claim that defects cost a hundred times more to fix later, though their projects all used one process (TSP) [5].
None of these studies tests a Definition of Done. Linking their findings to the Definition of Done is my inference: if low-quality work and accumulated technical debt harm the business, then shipping work that has not reached the minimum the business set for itself carries that harm.
Shipping below the Definition of Done takes a written C-suite signature, and the risk goes on the books
My position is that there are no waivers and no lax bars. Work that misses the Definition of Done is not Done.
The only route to shipping work below the minimum is a signed statement from the person who would answer to the board or the regulator for the harm. It accepts the risk to the business and to its customers, and it is recorded in the accounts against the claimed worth of the investment that paid for the work. That record names the risk accepted, the work it applies to and who signed, and it reduces the value the business can claim for that investment until the work reaches the minimum.
Nobody should be asked to sign it, and nobody should sign it. A CFO asked to lower the return on an investment, in writing, will send the team back to meet the minimum. That is the answer the route exists to produce. Asking “could we ship this anyway?” should end with “the CFO would never agree to that”.
In the organisations I work with, the alternative is that the same decision gets made in a team meeting or a chat thread, nobody records it, and the risk lands on customers without anyone at the top knowing.
A Definition of Done that cannot be met is the wrong Definition of Done
A Definition of Done that a team, a product or the organisation cannot meet is the wrong one for that level, and it has to change. Whatever it says, every team meets it, with no exceptions.
That needs a distinction between two kinds of “cannot”. “Cannot yet” is a capability gap. A team without automated security scanning cannot yet show that its work meets the security standard. The requirement stays. Until the gap is fixed, that team’s work is not Done and does not ship as Done. That is how the organisation sees the gap and decides to fix it, instead of discovering it after an incident.
“Cannot ever” means the nature of the product rules it out. A product that is installed on customer hardware cannot be “live in production” under the vendor’s control. A requirement like that never belonged in that product’s Definition of Done.
“Every team meets it” governs what counts as Done. It does not describe what every team can do today. A Definition of Done that some teams are quietly excused from is no longer a minimum, and the excused teams are where the gap is most likely to hurt a customer.
A Definition of Done can constrain the quality of what is built but must never decide what is built
A Definition of Done never contains scope. “Meets acceptance criteria” sets scope: it makes Done mean “we built what was asked”, which says nothing about whether the work is safe to ship. I have covered why acceptance criteria and the Definition of Done do different jobs elsewhere.
The Definition of Done can, however, constrain the quality of whatever scope is chosen. “Instrumented with telemetry that will support or weaken the hypothesis the work started from” does exactly that. It does not say which feature to build or what it should do. It says that whatever is built must be measurable against the reason it was built. I have made the case for telemetry belonging in the Definition of Done before.
If an item changes from one piece of work to the next, it is scope and belongs with the work. If it applies unchanged to every piece of work, it may belong in the Definition of Done.
A number in the Definition of Done becomes the target the work aims at
“80% code coverage” is a common Definition of Done item, and I think it is a poor one. It makes 78% a failure, even when the code at 78% is better tested than the code at 80% somewhere else. People then write tests to reach the number rather than to find defects.
Goodhart’s law, as it is usually stated, holds that a measure used as a target loses the relationship that made it useful [6]. The popular wording of that idea is Strathern’s [7]. Neither of them wrote about code coverage, and I found no study on coverage targets specifically, so the application to coverage is my judgement.
The alternative I recommend is “code coverage is the same or increasing”. It sets a direction rather than a threshold. No team fails because of where it started, and every team is held to not making things worse. Deleting unused code can lower the number for a good reason, and the team can show that it did.
That wording is also a measure, and I concede it can be gamed. My claim is narrower: a direction distorts behaviour less than a threshold.
Some thresholds are not the organisation’s to choose, because a regulation sets them. These enter the Definition of Done as an evidenced state, such as “meeting our regulatory obligations”, with the evidence attached to the work. The figure is owned by the obligation, not invented by the organisation.
A Definition of Done describes the state of the work, not the steps taken to reach it
“Code reviewed” and “QA signed off” are activities and handoffs. They can be satisfied by someone doing something, whether or not the work ends up in a good condition. “Releasable” and “meeting our security standards” are states. They are satisfied only if the work is actually in that condition.
A review can be rushed and still count as done, and a sign-off can be given to clear a queue.
Activities still matter. They are how a team reaches the state, and the team decides which activities it needs. The organisation’s Definition of Done should only name the states.
The organisation sets the minimum, and each product and team adds to it
The organisation sets one minimum Definition of Done for everyone. Each product adds what it needs to meet that minimum, and each team on a product can add more. Nobody removes anything.
For teams that use it, the Scrum Guide is consistent with this. It says that if the Definition of Done is part of the standards of the organisation, “all Scrum Teams must follow it as a minimum” [8]. The Guide does not say teams may add to it; that is my inference from “as a minimum”. The Guide also says teams sharing a product must mutually define their Definition of Done. My reading is that the organisation sets the minimum and the teams on a product mutually define anything above it.
Everyone working on the same product has the same minimum Definition of Done. Two teams shipping into one product under different minimums means the product is protected only to the lower of the two.
The organisation’s Definition of Done is high level: a few states, not a list of things to do. Products and teams keep their own lists of what it takes to reach those states. As long as they deliver to the organisation’s Definition of Done, nobody needs to prescribe what is on their lists.
Removing an item that no longer applies does not lower the minimum. If a law is withdrawn, the state that existed to meet it can go. The organisation’s minimum is raised over time and never lowered below what is needed to protect the business and its customers. Each rise in the minimum makes the product easier to add to and change, so raising it pays for itself in the work that follows. Tornhill and Borg’s finding that low-quality code takes longer to change [1] is the same effect seen from the other side.
Done can mean released or releasable, and the organisation decides which for every team
Done can mean released, live, and in use. Done can mean releasable, with the decision to release made separately.
On the Azure DevOps product team at Microsoft, where I worked with the team, the Definition of Done was:
Live and in production, collecting telemetry, supporting or diminishing the starting hypothesis.
That works for a service the team runs itself. Done means customers have it, and the team is already learning whether it was worth building.
“Releasable” fits organisations whose products ship on a customer’s schedule, through an app store, or onto hardware they do not control.
Which one applies is the organisation’s decision, for everyone. A team cannot say “this does not apply to us”. If “live in production” is impossible for some products, it is not their Definition of Done, and the organisation picks the form every team can meet. That usually means “releasable” at the organisational level, with products that can go further adding “live in production” as their own addition.
Test your own Definition of Done this week
Take your current Definition of Done and ask these questions of it:
- Does it contain scope, such as “meets acceptance criteria”?
- Does it contain a quantity target, such as a coverage percentage?
- Does it list activities and handoffs rather than states of the work?
- Is there a route by which work missing it can still be called Done?
- Can a team loosen it for its own work?
- Is there more than one minimum Definition of Done for a single product?
- Does it contain anything that not every team can meet?
- Is it silent on what it protects?
- Who in your organisation would sign to ship below it, and have they ever been asked?
A “yes” to any of the first eight is something to fix. An empty answer to the ninth means ownership has not yet been decided.
Then check whether ownership changes anything. If, after the accountable leaders take ownership, work that misses the Definition of Done still ships without a written acceptance from the top, ownership has changed nothing, and my argument fails. Then compare the incidents traced to work that shipped below the minimum in the six months before and the six months after.
Subscribe to Martin's articles
Writing since 2001
Articles, usually weekly on Mondays. One click to leave.
References
- Tornhill, A. and Borg, M. (2022). “Code Red: The Business Impact of Code Quality”. TechDebt 2022. arXiv:2203.04374. https://arxiv.org/abs/2203.04374
- Besker, T., Martini, A. and Bosch, J. (2019). “Software Developer Productivity Loss Due to Technical Debt: A replication and extension study examining developers’ development work”. Journal of Systems and Software, 156, 41-61. https://doi.org/10.1016/j.jss.2019.06.004
- Krasner, H. (2022). The Cost of Poor Software Quality in the US: A 2022 Report. Consortium for Information and Software Quality (CISQ). https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
- DORA. “DORA’s software delivery metrics: the four keys”. https://dora.dev/guides/dora-metrics-four-keys/
- Menzies, T., Nichols, W., Shull, F. and Layman, L. (2017). “Are delayed issues harder to resolve? Revisiting cost-to-fix of defects throughout the lifecycle”. Empirical Software Engineering, 22(4), 1903-1935. https://arxiv.org/abs/1609.04886
- Goodhart, C.A.E. (1975). “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics, vol. 1, Reserve Bank of Australia.
- Strathern, M. (1997). “‘Improving ratings’: audit in the British University system”. European Review, 5(3), 305-321. https://doi.org/10.1002/(SICI)1234-981X(199707)5:3<305::AID-EURO184>3.0.CO;2-4
- Schwaber, K. and Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/scrum-guide.html
Was this useful?
Enjoyed this? One click, no account.
Questions this answers
Who should own the Definition of Done in an organisation?
The minimum Definition of Done belongs to the people accountable for protecting the business and its customers, typically business leadership, not engineering. Engineering advises on it and meets it, but leaders who would answer to the board or regulators if harm occurs must own and set the minimum bar.
What should a good organisational Definition of Done include and how should it be structured?
A good organisational Definition of Done is a small set of objective states that protect the business and its customers, such as being integrated, releasable, meeting quality and security standards, and instrumented with telemetry to test the original hypothesis. It must describe states of the work, not activities or scope, avoid arbitrary numeric targets, and act as a minimum that products and teams can add to but not weaken.
What does it mean to ship work that is not Done and why is it harmful?
Shipping work that has not reached the Definition of Done is a false value proposition, because it only looks like delivery while introducing low-quality code, defects, and technical debt that increase costs and slow future work. Evidence from multiple studies links poor quality and technical debt to more defects, longer resolution times, and substantial economic impact, implying that shipping below the minimum Definition of Done harms both the business and its customers.
How should an organisation handle exceptions when work does not meet the Definition of Done but there is pressure to ship?
If work misses the Definition of Done, it is not Done and should not quietly ship; the only route to shipping below the minimum is a written, signed acceptance of risk from the accountable C‑suite leader, recorded against the investment’s value until the work is brought up to the minimum. This deliberate, documented path is designed to make such exceptions vanishingly rare by forcing top-level acknowledgement of the risk and its financial impact.
What should an organisation do if its current Definition of Done cannot be met by some teams or products?
If a Definition of Done cannot be met, it must change: every team must be able to meet it with no exceptions, or it ceases to be a true minimum. Capability gaps that mean teams cannot yet meet it should be exposed and fixed while work is treated as not Done, whereas requirements that are impossible by the nature of a product never belonged in that product’s Definition of Done and should be removed or relocated to the appropriate level.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.