"I'm done with the payments story. It just needs testing."
Every standup has heard a version of that sentence, and everyone in the room nods along, because everyone knows what it means: the story is not done. It compiles, it probably works on the developer's machine, and somewhere between here and production there's an unknown amount of work that nobody estimated, nobody scheduled, and nobody will remember agreeing to. Two days later the same story is "done, it just needs a review". Then "done, waiting on the deploy". The story spends a week in the Done-adjacent suburbs before it ever ships, if it ships this sprint at all.
Done is the most quietly abused word in software teams. Not because anyone is lying. Because everyone is telling the truth against a different definition.
Five people, five definitions
Ask five members of the same team what done means and you'll get five honest, incompatible answers. The developer means the code works when they exercise it by hand. The tester means it survived their scenarios. The product owner means the stakeholder saw it and didn't wince. The ops-minded person means it's in production behind a flag with a dashboard watching it. The new hire means whatever the ticket status says.
None of these people is wrong. They're just not answering the same question, and the gaps between their answers don't show up in conversation. They show up later, as symptoms: stories that carry over sprint after sprint at "90% done", bugs that surprise everyone because testing was somebody's silent assumption, a velocity number that looks healthy right up until you ask how much of last sprint's "done" work is actually in front of users.
A Definition of Done is the team's shared answer to that question, written down. That's all it is. Not a governance artifact, not a quality management system, not a wiki page with a revision history longer than the content. A short list that turns "done" from a feeling into a checkable claim.
The operative word is short. A DoD only works if people actually run through it, story after story, without ceremony. The moment it becomes a document people acknowledge rather than apply, it's decoration.
What goes in the first version
If your team doesn't have a DoD, or has one nobody has read since it was written, start with four to six items. Something like:
- Code reviewed by at least one other person
- Tests written and passing, at whatever level the team can honestly sustain
- Deployed to staging, or to production if that's your normal flow
- No known regressions in what already worked
- Product owner has seen it working, not just heard about it
That's it. Five items, each verifiable in under a minute, each one something the team controls. You could recite this list from memory during standup, and that's precisely the point. A DoD you can't remember is a DoD you won't use.
Notice what these items have in common: every one of them applies to every story, and every one of them can be checked by the team without asking anyone's permission. Those two properties are the filter for everything you're tempted to add later.
What stays out
The failure mode of DoDs is not that teams skip writing one. It's that they write a good one and then feed it until it dies. Three categories of item do most of the killing.
Aspirational items nobody enforces. "Performance tested under production-like load" sounds professional. If your team has no load testing setup and no plan to build one, it's fiction, and one fictional item poisons the rest. Once people learn that some checkboxes are decorative, they start deciding for themselves which ones are real. Now you don't have a shared definition anymore; you have a menu.
Process steps that vary per story. "Designs approved by UX" is a fine expectation for stories that have designs. Half your stories are API changes and refactors that never touch a pixel. An item that only sometimes applies trains people to skim, and skimming is a habit that doesn't stay contained.
Anything the team can't verify itself. "Approved by the architecture board" turns your DoD into a queue for someone else's calendar. If done depends on people outside the room, the team no longer controls whether its own work is finished, and the DoD becomes a list of excuses instead of a list of checks. Where an external step genuinely exists, model it as an explicit workflow stage, not a line item the team pretends to own.
One clean separation worth making explicit: the Definition of Done is not acceptance criteria, and mixing them is how DoDs bloat. The DoD applies to every story, unchanged, sprint after sprint: reviewed, tested, deployed, no regressions. Acceptance criteria belong to one story and describe what that particular story must do: the export includes the legacy CSV format, the error message names the field. If you find yourself writing story-specific detail into your DoD, it's an acceptance criterion that wandered into the wrong document. Send it home. Good acceptance criteria are their own craft, and they do a lot of the heavy lifting when it comes to writing user stories that are easy to estimate.
Your team already wrote its real DoD
Here's the diagnostic that costs nothing. For the next two sprints, every time someone says "done except" or "done, but" or "done, it just needs", write down what comes after. Don't comment on it, don't correct anyone, just collect.
At the end of two sprints you'll be holding a list that reads something like: except testing, except the review, except deploying it, except the edge case with empty accounts, except updating the docs. That list is your team's real Definition of Done, drafted by the team itself, in its own words, from its own working habits. Every entry is a gap between what people call done and what done needs to mean.
Bring the list to a retrospective and turn the most frequent entries into your DoD. This lands completely differently from importing a template, because nobody can argue the items are theoretical. The team watched itself say them. If you run retrospectives in ScrumMastr, this makes a strong themed session: one column for "things we said after done except", one for "which of these should done actually include".
Undone work is invisible scope
The DoD isn't just a quality tool. It's an estimation tool, and this is the part teams consistently miss.
When you estimate a story, you're estimating the work to get it done. If done includes writing tests, the estimate includes writing tests. If done includes deploying and verifying, the estimate includes that too. A story estimated without the DoD in mind is underestimated by definition, because the undone work doesn't vanish. It just becomes invisible scope: unplanned effort that surfaces later as carry-over, hotfixes, and the mysterious drag on next sprint that nobody can point to.
This is why teams that adopt a real DoD often watch their estimates rise and panic. A story that used to be a three becomes a five. Nothing got slower. The three was always a lie; the five is what the work cost all along, with the previously hidden portion now on the books. Velocity dips on paper and becomes honest in practice, which is a trade you should take every single time. When your team is estimating together, planning poker or otherwise, it's worth someone asking out loud: "is that estimate for done-done, per our DoD?" You'll be surprised how often the answer changes the number. The same honesty applies upstream too, in how much you prepare stories before they reach planning, which is its own balancing act covered in Backlog refinement: how much is enough?.
Tighten the ratchet, one click at a time
A first DoD should describe what your team can genuinely do today, not what it wishes it did. If your test coverage is thin and your deploy is manual, a DoD demanding automated tests and continuous deployment isn't a standard, it's a wish, and wishes get waived.
So start loose and honest, then ratchet. Every few months, tighten one item. "Tests written where practical" becomes "automated tests for all new logic". "Deployed to staging" becomes "deployed to production behind a flag". One item at a time, and only after the capability exists, because adding "automated tests" to a document does not create testing skill. Sequence the investment first: the tooling, the pairing, the time to learn. Then codify what the team can already do, so the DoD confirms a capability instead of demanding one. A ratchet that only tightens when the underlying strength is there never has to slip backwards, and a DoD that has never been waived is worth ten ambitious ones that have.
When the deadline wins anyway
It will. Some sprint, someone senior will need the feature out and the team will ship it without the review, or the tests, or the staging soak. Pretending this never happens is how DoDs lose credibility.
What matters is being clear-eyed about the price. The skipped work doesn't disappear; it lands in the next sprint's velocity, invisibly. Nobody schedules "write the tests we skipped", but the next stories in that area go slower, the regression that testing would have caught eats a day and a half, and the team quietly delivers less while working just as hard. You paid for the shortcut with money from an account nobody checks.
If you must break the DoD, break it in the open. Say it in planning, write the skipped items down as explicit follow-up work, and put them in the next sprint where they cost visible capacity instead of invisible drag. A violated DoD with a paper trail is survivable. A violated DoD everyone politely ignores is the first step back to five private definitions.
Leave it alone
Last piece of advice, and it cuts against the instinct to continuously improve everything: don't tinker with your DoD every retro. A Definition of Done earns its power from stability. If the meaning of done shifts every two weeks, your velocity baseline shifts with it, nobody internalizes the list, and the document becomes one more thing to keep up with instead of a thing you know.
Review it deliberately twice a year. Ask three questions: is every item still real, is anything getting waived often enough that it's fiction, and has the team grown a capability worth ratcheting in. Change at most one or two things, then leave it alone again. Between reviews, the DoD's job is to be boring, memorized, and applied to every single story without discussion. Boring is what done is supposed to feel like.