Definition of Done: A Practical Checklist for Sprint-Based Delivery

Ask five engineers on the same team what "done" means and you'll usually get five slightly different answers — code merged, tests passing, deployed, documented, demoed. All five are partially right, which is exactly the problem: partial agreement on "done" is how scope quietly slips every sprint without anyone deciding it should.

This is the checklist our pods use. It's short on purpose — a definition of done that's too long gets skipped under deadline pressure, which defeats the point.

The checklist

A story is done when, and only when:

1. It's reviewed and merged — not "approved and waiting," actually merged to the branch that matters.
2. It has test coverage proportionate to its risk. Not 100% coverage everywhere — coverage matched to what actually breaks if this is wrong. A config change and a payment-handling change don't need the same coverage bar.
3. Documentation reflects the change — README, API contract, or setup instructions updated in the same sprint, not queued for "later" (later rarely comes; see our documentation-as-you-go standard).
4. It's demoed, working, in the environment it's meant to run in — not just on the author's machine. A feature that "works locally" and hasn't been shown running where it'll actually run isn't done, it's a claim.

That's the whole list. Four items, deliberately. Every extra item added to a "definition of done" checklist is a real cost — teams either enforce a longer list rigorously (rare) or quietly start skipping items (common), and a partially-enforced long checklist is worse than a fully-enforced short one.

What's deliberately not on this list

• "Deployed to production." Deploy cadence is a separate decision from whether a story is done — a done story might sit in a release branch waiting for a coordinated launch. Conflating the two makes "done" hostage to release scheduling.
• "Zero known bugs." No sufficiently real feature ships with zero known anything. What matters is whether known issues are triaged and tracked, not whether the count is literally zero.
• "Stakeholder sign-off." That's a separate approval gate, not a technical completion criterion — bundling them means a story can be technically done and organizationally stuck, and calling it "not done" hides that distinction.

Why the demo requirement does the most work

Of the four items, the sprint demo requirement catches the most real problems, because it's the only one that can't be faked by checking a box. Code can be merged with weak tests. Documentation can be updated superficially. But you can't demo something that doesn't actually run — the demo is where "I think this works" becomes "I watched this work."

This is also why our pods run fixed-length sprints that always end in a demo, not a status update (see our engineering standards overview for the full sprint cadence). A demo due Friday is a forcing function nothing else on this list replicates.

Using this with a client or stakeholder team

If you're adopting this checklist with a team that isn't used to a hard definition of done, the fastest way to make it stick is to apply it retroactively to the last completed sprint before rolling it forward: which of the last sprint's "done" stories would actually have passed all four? That exercise usually surfaces the gap faster than explaining the checklist in the abstract.