Definition of Done: The Checklist That Stops Rework

A definition of done is a shared checklist that every piece of work must pass before the team calls it finished. It applies to every ticket, not just one, and covers quality steps such as code review, testing and documentation. If an item fails any check, it is not done.

Without one, "done" means whatever the last person to touch the ticket thought it meant. That is how a feature ships without tests, gets reopened a week later and quietly eats the next sprint.

Definition of done vs acceptance criteria

These two get confused constantly, so it is worth being precise:

• Acceptance criteria are specific to one story. "A user can reset their password from the login page" is an acceptance criterion.
• The definition of done is universal. "Code reviewed by another developer" applies to the password story, the CSV export and the typo fix alike.

A story is finished only when it meets its own acceptance criteria and the team's definition of done. For more on the story side, see how to write user stories.

A definition of done example

Here is a starting point for a typical web delivery team. Trim or extend it to fit your context:

1. Code is merged to the main branch and linked to the ticket.
2. Another developer has reviewed it.
3. Automated tests pass and new logic has tests.
4. The ticket has been tested by someone other than the developer, and the result is recorded.
5. Any user-facing change is documented, or release notes are drafted.
6. The product owner, or the client where relevant, has accepted it.

Notice that every line can be verified. "Code is clean" is not a check; "reviewed by another developer" is.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

How to make it stick

A definition of done that lives in a forgotten document does nothing. Make it visible and make it hard to bypass:

• Put it on the board. If your board has a Testing column, done cannot happen without passing through it.
• Review it in retrospectives. If bugs keep escaping, add a check. If a check never catches anything, question whether it is worth keeping.
• Keep it short. Six to eight items is plenty. A 25-point checklist gets skipped.
• Make the evidence automatic. Each check should leave a trace, such as a recorded test result or a sign-off, so nobody has to take anyone's word for it.

Levels of done

Mature teams often have more than one level: done for a story, done for a sprint, and done for a release. Release-level done might add a regression run, a client sign-off and a deployment checklist. Our release checklist guide covers that last layer.

How Flow helps

Jira lets you express a definition of done through workflow conditions and, with marketplace apps, checklists on each issue. Teams looking for a Jira alternative often want the checks enforced by the process itself. Livex Flow approaches it this way:

• Process Flow with transition rules stops a ticket jumping from In Progress to Done without passing through review and testing.
• Governed stages can only be entered by automation, so a "Tested" stage is reached because a test passed, not because someone dragged a card.
• Test runs with pass/fail per ticket record who tested what and when, and failure history stays on the ticket.
• Client sign-off gives you a formal, auditable "accepted" step for work that needs client approval.