When "Done" Means Nothing: Fixing a Weak Definition of Done
On paper, almost every Scrum Team has a Definition of Done. In practice, far fewer have one that means anything. The Scrum Guide is blunt about why it matters: the Definition of Done is the team's shared, formal commitment to quality. When an Increment meets it, it is releasable. When it doesn't, the work is not Done — it simply goes back into the Product Backlog. The trouble is that many teams treat the Definition of Done as a poster on the wall rather than the gate it is supposed to be.
The cost of a weak one is rarely visible in a single Sprint. It shows up later — as a backlog of "finished" features that still need testing, integration debt that surfaces during a release, or a Product Owner who quietly stops believing the Sprint Review. After eighteen months of disrupted supply chains and half-remote teams, a lot of organizations have been carrying exactly this kind of hidden rework, and only noticed when they tried to ship.
How a Definition of Done Goes Soft
It describes activities, not outcomes. "Code written, tests written" tells you what people did, not whether the result works. A useful entry is verifiable: "automated tests pass in the integration environment," not "we wrote tests."
It is aspirational, not honest. Teams list what they wish they did — full regression, security scan, documentation — then quietly skip half of it under deadline pressure. A Definition of Done you routinely violate is worse than a short one you actually keep.
It lives only in the Developers' heads. If the Product Owner and stakeholders cannot say what Done means, the Sprint Review becomes a negotiation about whether something is really finished. That argument should have been settled before the work began.
It stops at the team boundary. When deploy, accessibility, or data-migration steps belong to "someone else," the Increment isn't actually releasable. Hybrid and distributed teams feel this most, because the handoffs are invisible until they fail.
It never changes. A Definition of Done set a year ago, before a new compliance rule or a new platform, is quietly out of date. It should evolve as the team's capability and context evolve.
Putting the Teeth Back In
The fix is not a longer document. It is a shorter, truer one that the whole team actually enforces. Start by writing each item so anyone can check it without debate — pass or fail, no interpretation. Then test the list against reality: in the last three Sprints, did every Increment you called Done genuinely meet every line? If not, either change the behaviour or change the line, but close the gap.
Make each criterion observable and binary — it is met or it is not, with no "mostly."
Cover the whole path to releasable, including the steps currently owned by people outside the team.
Review the Definition of Done in the Retrospective, not just when something breaks.
Treat work that misses it as not Done — return it to the Product Backlog rather than bending the rule.
Keep it visible and shared, so the Product Owner uses the same bar the Developers do.
A Definition of Done with teeth changes the tone of a Sprint Review. Instead of debating whether a feature is finished, the team demonstrates an Increment everyone already trusts. That trust is the real deliverable — it lets a Product Owner forecast honestly and lets stakeholders plan around something solid. For organizations still untangling pandemic-era backlogs, that reliability is worth more than another burst of output.
If your teams are shipping work that keeps coming back, XNM's program & project delivery advisory can help you rebuild a quality standard your whole organization will actually trust.