Definition of Ready vs Definition of Done: a practical guide

Definition of Ready and Definition of Done get confused often enough that it's worth stating the difference in one line each: Definition of Ready is the bar an issue clears before it's allowed into a sprint. Definition of Done is the bar an issue clears before it's allowed to be marked finished. One gates the start of work, the other gates the end, and a surprising amount of sprint dysfunction traces back to a team having a clear one of these and no real version of the other.

Definition of Ready: is this actually workable?

An issue can be written, prioritized, and sitting at the top of the backlog and still not be ready to work on. Ready means someone can pick it up and make progress without stopping every twenty minutes to ask a question that should have been answered before sprint planning. A useful Definition of Ready is concrete, not aspirational: acceptance criteria are written down, not implied; known dependencies are identified, even if not yet resolved; the issue has a size or estimate attached; and if it involves a UI, a mockup or reference exists. None of that guarantees the work goes smoothly, but it rules out the specific and common failure of committing to something in sprint planning that turns out to be three unanswered questions in a trench coat.

The test for whether a Definition of Ready is real: could a competent engineer who wasn't in the planning meeting start this today from the ticket alone? If the honest answer is 'they'd need to ask someone first,' it wasn't ready, no matter how confidently it got pulled into the sprint.

Definition of Done: is this actually finished?

'Done' is the most overloaded word on any team, because it silently means different things to different people — the engineer means the code is merged, the PM means it's live for users, QA means it's been tested, and none of them are wrong, they're just answering different questions with the same word. A Definition of Done exists to collapse that ambiguity into one team-wide checklist: code merged to the target branch, tests passing, deployed to the environment that counts as 'live' for this team, and documentation or changelog updated if the change is user-facing. It's set once, per team, and applied uniformly — the whole point is that nobody has to ask 'wait, does done mean deployed or does it mean merged' on a per-issue basis anymore.

It's worth being explicit that 'done' and 'closed' aren't identical either. Some teams close an issue the moment code merges and let deployment happen separately; others hold the issue open until it's live in production. Either is defensible — what's not defensible is a team where half the people believe one and half believe the other, because that's where 'didn't we already ship this?' conversations come from.

What skipping each one actually looks like

Skip a real Definition of Ready and the failure shows up mid-sprint: an issue gets started, the engineer discovers it depends on a decision nobody made, and it sits blocked for three days while the sprint's committed capacity quietly evaporates. This is the single most common cause of a sprint that looked reasonably planned on Monday and looks nothing like the plan by Thursday — not bad estimation, but issues that were never actually ready to start.

Skip a real Definition of Done and the failure shows up at review or, worse, in production: something gets marked complete that was never tested against the edge case that mattered, or that's technically merged but not actually deployed anywhere a user can see it. The cycle review is where this usually surfaces — 'what shipped' and 'what we thought shipped' turning out to be different lists is almost always a Definition of Done problem wearing a different name.

Who actually owns each checklist

The two checklists work best when different people own them, because they're accountable to different questions. Definition of Ready is usually the responsibility of whoever grooms the backlog — a PM, a tech lead, sometimes the whole team in a grooming session — because 'is this workable' is a question about the ticket, decided before the team commits to it. Definition of Done is owned collectively by the team as a standing agreement, not re-litigated per issue, because 'is this finished' should mean the same thing for every ticket regardless of who wrote it or who's reviewing it. Mixing the two up — letting an individual engineer redefine 'done' for their own ticket, or letting a whole team argue readiness fresh every single time — is where both checklists quietly stop functioning as checklists and turn into whatever the loudest voice in the room decided that day.

Keeping both alive without turning them into bureaucracy

The failure mode on the other side is a checklist so long and so rigidly enforced that it becomes theater — five minutes of box-ticking that nobody actually reads before checking every box anyway. Keep both short enough to fit in a sentence or two, attach them to the workflow states themselves rather than a separate document (a 'Ready' column an issue only enters once its criteria are met is a Definition of Ready that enforces itself), and revisit them every few cycles rather than treating them as fixed forever. A sprint planning session that starts with a genuinely ready backlog is a different, shorter meeting than one spent discovering which issues aren't actually workable yet — and an AI draft of the sprint is only as good as the readiness of what it's drafting from.

If backlog grooming is where 'ready' keeps breaking down, AI triage can help catch the gaps — flagging issues that are missing acceptance criteria or a size before they ever reach planning, rather than discovering the gap once the sprint's already started.