Definition of Ready and Definition of Done

Definition of Done (DoD) is a team-owned, explicit checklist describing what "finished" means for any piece of work — agreed once, applied consistently, not re-litigated story by story. Without one, "done" means something different to whoever's asked: a developer might mean "the code works on my machine," a QA engineer might mean "it's been tested," a Product Owner might mean "it's actually live for users" — three genuinely different, all reasonable, definitions, colliding every single time the question comes up.

A representative Definition of Done:

Crucially, this is the same checklist for every story — a story isn't "done" for some looser, story-specific definition just because it's a rush job or a small change. The whole value of a Definition of Done is that it's a fixed bar, not a negotiable one, so "done" stops being decided by whoever's asking and starts meaning one specific, shared thing.

Without an explicit DoD, "done" quietly drifts toward whatever's convenient in the moment — a story gets marked complete because the code is merged, even though it's untested; a sprint's velocity looks healthy because eight stories are "done," except four of them are actually done-except-for-QA, done-except-for-docs, done-except-for-a-known-bug. This is one of the most common causes of a sprint that looked successful on the burndown chart but produced an increment that wasn't actually shippable — the team's own numbers were quietly inflated by an inconsistent, unstated bar for "finished."

Definition of Ready (DoR) is the same idea applied to the start of work instead of the end — a checklist a backlog item should meet before it's eligible to be pulled into a sprint at all:

A story that fails this checklist and still gets pulled into Sprint Planning is exactly what causes the mid-sprint scramble covered in the backlog-refinement lesson — a developer discovers, three days into implementation, that a key question was never actually answered, and now the sprint's plan has to be renegotiated with information that should have surfaced during refinement, before the sprint even started.

There's no canonical, one-size-fits-all Definition of Done or Ready — a team building a regulated financial product's DoD reasonably includes a compliance sign-off; a small internal tool's DoD reasonably doesn't. What matters isn't matching some external template, it's that the team has actually agreed on one explicitly, written it down somewhere visible, and applies it consistently rather than deciding "done enough" story-by-story based on mood, deadline pressure, or who's asking.

Neither definition should be treated as permanently fixed the moment it's written. A team that keeps discovering post-release bugs that manual testing should have caught probably needs to strengthen its DoD's testing bar; a team whose Sprint Planning keeps stalling on the same category of missing information probably needs to add that category explicitly to its DoR. Both checklists are working documents the team owns and adjusts, usually surfaced as a natural retrospective topic when the same kind of problem keeps recurring.