Quality & Team

Definition of Done

Foundational

"Done" should mean the same thing for everyone, not "the code compiles on my machine". A shared Definition of Done is the checklist that says the work is genuinely finished: tested, reviewed, secure, documented, observable, and actually working in production. It stops half-finished work from becoming a colleague's problem later.

The most common source of friction and bugs on a team is an unspoken, inconsistent idea of "done". One person means "I wrote the code". The next expects tests, docs, and a working deploy. A Definition of Done makes the standard explicit and shared, so nothing important is skipped and nobody has to guess. It brings together many other guidelines into one checklist.

For a mostly-junior team this is especially valuable. It writes down the standard, so good practice does not depend on experience or memory. Done means done: the user's problem is solved, safely and maintainably, in production.

What 'done' includes

DoThe feature meets the requirement and handles the edge and error cases, not just the happy path (see Error Handling).
DoTests are written and passing for the behaviour, especially security and compliance-critical paths, and the pipeline is green (see Testing Strategy, CI/CD).
DoIt has been reviewed (paired or PR) and meets coding standards, and security and tenancy concerns were considered (see Code Review, Coding Standards).
DoDocs, comments, and any runbook or config are updated, and the change is observable (logs and metrics) so you would know if it broke (see Documentation as Code, Observability).
DoIt works in production (or is safely behind a flag), and the original problem is genuinely solved (see Ownership & Accountability, Feature Flags).
AlwaysTreat security and compliance requirements as part of Done, never an add-on for later. A feature is not done if it is not safe (see Security by Design).

'Done' means the code is written

// merged the feature; no tests, no error handling on the fail path,
// no logging, told everyone "it's done"

It looks finished but it is not. The failure path is untested and silent, nobody will know if it breaks, and the next person inherits the missing half. This is how 'done' work causes incidents.

Measured against Done

// feature + edge/error cases handled; tests green incl. fail-closed path;
// reviewed; logging/metrics added; works in prod behind a flag;
// the customer's problem is actually solved

Each part of Done is met, so the work is genuinely finished and will not come back as a surprise.

Use it honestly

DoCheck the work against the shared Definition of Done before calling it done. Make it a habit, not a formality.
DoIf something on the list is genuinely left for later, say so clearly and track it. Do not quietly call it done (see Technical Debt, Professional Ethics).
Avoid"Done except for tests, docs, or error handling" as a quiet default. That is not done. It is passing unfinished work to whoever is next.
ConsiderAdjusting the checklist per team or work type, but keeping the core (tested, reviewed, secure, working) non-negotiable.

Self-review checklist

AskIs this tested (including error, edge, and security-critical paths) with a green pipeline?
AskIs it reviewed, up to standard, with security and tenancy considered?
AskIs it observable and documented enough that I would know if it broke and others can run it?
AskDoes it actually work in production and solve the real problem, or am I calling 'code written' done?

Why it matters: An inconsistent idea of "done" is where half-finished work, surprise bugs, and missing safeguards come from, and each one lands on a colleague or a customer later. A shared Definition of Done makes the full standard explicit and routine. That keeps quality high and predictable even as a growing, junior team moves fast.