Definition of done: what it is, with examples

The Scrum Guide describes the definition of done as a formal description of the state work must reach to meet the quality the product needs. In plain terms: a checklist that applies to every card, whatever the card is about.

If a card doesn't meet it, it isn't done. It doesn't count as finished, it doesn't get shown at the review, and it isn't released. That rule is the whole point. Without it, "done" means "done, except for the tests", and the gaps pile up where nobody can see them.

When an organisation already has a standard, every team follows it as a minimum. Otherwise the team writes its own.

They're often confused, and they work together:

• Acceptance criteria belong to one card. They say what that piece of work must do: "A customer can pay by card", "The export includes archived cards".
• The definition of done belongs to all cards. It says what every piece of work must have gone through: reviewed, tested, documented, released.

A card is finished when it meets its own acceptance criteria and the definition of done. See acceptance criteria examples, and the definition of ready for the check before work starts.

A software team

• Code reviewed by someone who didn't write it
• Automated tests written and passing
• Works in the browsers and devices the product supports
• Docs and the changelog updated where users will notice
• Deployed to production, or ready to deploy with one step

A content team

• Edited by someone other than the writer
• Facts and links checked
• Images have alt text
• Title and meta description written
• Published, or scheduled with a date

A design team

• Reviewed with the person who asked for it
• Covers the empty, loading and error states
• Checked for contrast and keyboard use
• Handed over with the assets and notes developers need

1. Write it together. A list handed down gets ignored. A list the team argued over gets used.
2. Keep it short. 4 to 7 items. Each should be something people actually skip when rushed.
3. Make each item checkable. "Tests pass" can be checked. "Good quality" can't.
4. Only include what the team can do. If release depends on another team, say "ready to release", not "released".
5. Put it where the work is. A definition of done in a wiki nobody opens is no definition at all.
6. Revisit it. Raise it at retrospectives. Add an item when something keeps slipping, and remove one nobody needs.

• Making it a wish list. If the team can't meet it on every card, it will be ignored on all of them.
• Bending it under deadline. Shipping one card that isn't done teaches everyone the list is optional.
• Mixing it with acceptance criteria. Card-specific requirements don't belong on a list that applies to everything.
• Never changing it. As the team and product grow, what done needs to mean grows too.

A board makes done visible: a card is either in the done column or it isn't. In craaft:

• Write the definition of done in the board brief, where everyone on the board can read it, and agents read it with the board.
• Add the items as a checklist on cards that need them, so progress shows on the card.
• Use a review column, like In Review in the sprint planning template, for the check before a card moves on.
• Mark the last column as a done column. Cards there count as finished and drop out of Focus and the open counts.