Definition of done — what 'finished' actually means

A task can compile, run correctly for the happy path, and still not be done — no tests, no error handling for an obvious failure case, a hardcoded value that only worked because of the specific data on your machine. "It works" and "it's done" sound similar but make different claims, and treating them as the same is how a task gets marked complete, merged, and then reopened a week later as a bug.

Teams that avoid this ambiguity write down, once, what "done" means for any normal piece of work — not per-task, but as a standing checklist applied to every task by default:

This list isn't universal — a team's actual definition of done should match its own real risks (a team shipping to production multiple times a day cares about different things than one shipping monthly) — but having one written down and applied consistently is the part that matters, more than its exact contents.

A task that's 90% done in the sense of "the interesting part works" but still needs tests, edge-case handling, and review often takes as long for that last 10% as the first 90% did — a pattern experienced engineers eventually stop being surprised by. Reporting a task as "done" when it's actually at that 90% mark isn't dishonest so much as measuring a different, less useful thing than what "done" is supposed to mean to everyone else relying on that status.

A shared, explicit definition of done removes an entire category of disagreement — "I thought this was ready" vs. "there's no tests and it crashes on empty input" stops being a values disagreement and becomes a simple checklist check. It also protects the person who did the work: a clear, met checklist is a much stronger answer to "why isn't this actually finished" than a vague sense that it should have been enough.