Definition of done and definition of ready, without the bureaucracy

Ask five people on a team whether a story is done and you can get five different answers. The developer means the code is written. The reviewer means it passed review. The tester means it works. The product owner means it is live and a customer can use it. Everyone is telling the truth, and everyone means something different, which is exactly how a story gets marked done on Friday and reopened on Monday.

A definition of done is the small agreement that ends that argument before it starts. Its partner, a definition of ready, does the same job at the other end of the sprint. Neither needs to be a policy document. Both just need to exist and be honest.

Definition of done: one shared finish line

A definition of done is a short checklist of what must be true for any story to count as finished. Not this story in particular, every story. It is the team's shared quality bar, agreed once and applied to everything, so that "done" stops being a matter of opinion.

What goes on it depends on how your team works, but a typical one is short and unglamorous:

• Code is written and meets the team's standards.
• It has been reviewed by someone else.
• Tests are written and passing.
• It is merged and deployable.
• Any relevant documentation is updated.

That is often the entire thing, five lines. The value is not in the list being clever; it is in it being shared. Once the whole team has agreed that "done" includes reviewed and merged, nobody can quietly redefine the word to mean "done on my machine," and the count of finished work starts to mean something real.

Definition of ready: the entry gate

If the definition of done is the exit gate of a sprint, the definition of ready is the entrance. It is a short agreement about what a story needs before the team is willing to pull it in and commit to it. The point is to stop half-formed work from entering a sprint, sitting there for a week, and blocking on a question that should have been answered before it ever started.

A workable definition of ready usually asks that a story is:

• Clear. Anyone on the team can read it and understand what is being asked and why.
• Estimated. It has a rough story point size, which doubles as a check that everyone pictures the same work.
• Small enough. It fits comfortably inside one sprint. Anything larger gets split first.
• Unblocked. It does not depend on some other unfinished thing to even begin.

This is not a new activity bolted onto your week. It is precisely what backlog refinement produces when it is working: the top of the backlog is kept ready, so by the time you plan, the stories already clear the bar. Ready is just the name for the finish line of refinement.

How this differs from acceptance criteria

The most common confusion is between the definition of done and acceptance criteria, and the distinction is simple once you see it. The definition of done is general: it applies identically to every story. Acceptance criteria are specific: they describe what one particular story must do.

Take a story for a password reset. Its acceptance criteria are about that feature. The user receives a reset email, the link expires after an hour, an invalid token shows a clear error. Those criteria mean nothing for the next story about, say, exporting a report. The definition of done, meanwhile, is identical for both: reviewed, tested, merged. A story is genuinely complete only when it satisfies both its own acceptance criteria and the team's universal definition of done. One is the per-story detail, the other is the bar underneath everything.

Keep both short, or nobody uses them

Here is the failure mode to fear. A team gets enthusiastic, and the definition of done grows into a twenty-item compliance checklist covering every edge case anyone ever hit. It looks thorough. It is also dead. Nobody reads a twenty-item list before closing a card, so people stop consulting it entirely, and a checklist nobody checks is worse than none, because it creates a false belief that quality is handled.

Fight for brevity. A definition of done that fits on a sticky note and is genuinely followed beats an exhaustive one that lives in a wiki nobody opens. The same goes for ready. If clearing the bar becomes its own bureaucracy, teams route around it, and you are back where you started.

Treat both as living, too. When something keeps slipping through, a whole class of bugs that keeps reaching production, add a line. When a check has become a rote box nobody thinks about, cut it. A quick look at whether these are still serving you is a natural thing to raise in a retrospective, which is exactly where a team should be adjusting how it works.

Make the finish line visible

Both definitions do their job only when they are in front of the people using them, at the moment they are used. A definition of done that lives three clicks deep in a settings page is a definition of done nobody applies. Keep it where the work is, so glancing at it before you move a card is effortless rather than a detour.

That is the small discipline worth building: a shared bar for starting and a shared bar for finishing, both short, both visible, both honest. In Scrumpy the backlog and the board sit side by side, so keeping stories ready before they enter a sprint and honestly done before they leave it are ordinary, in-view actions rather than process you have to remember. Start a board and write your first three-line definition of done on it. You can always add the fourth line the first time you need it.