Quality Criteria

What quality standards must work meet to be done?

All code has been peer-reviewed and approved by at least one other developer.
Unit test coverage meets our agreed threshold of 80% or higher.
No critical or high-severity bugs remain open.
Documentation & Communication

What needs to be documented or shared before done?

User-facing documentation has been updated to reflect the change.
Release notes and changelog entries are complete.
API documentation reflects any new or changed endpoints.
Testing & Validation

How do we verify the work actually works?

Acceptance criteria from the user story have all been met.
Manual testing completed across supported browsers and devices.
Feature validated by the product owner before closing.
Deployment & Readiness

What must be true to safely release the work?

Feature is deployed to production or behind a feature flag.
Monitoring and alerting are configured for the new functionality.
A rollback or recovery plan is in place if something goes wrong.

What is the Definition of Done?

Ever shipped something only to find it wasn't really finished? A Definition of Done (DoD) is your team's shared list of criteria that every piece of work has to meet before anyone calls it complete. It applies to every user story, feature and increment, so "done" means the same thing whoever did the work. In Scrum, the Definition of Done is the quality bar for each increment. Writing it down ends the "is this finished?" debates at review time and stops hidden work, like missing tests or docs, from rolling into the next sprint. This session gets developers, testers, designers and product owners to build the list together, so it covers the steps each of them knows tend to get skipped. The board has four columns: Quality Criteria, Documentation & Communication, Testing & Validation, and Deployment & Readiness. Everyone adds criteria, then the team groups and votes on them to agree the list. Treat the result as a living document and revisit it as your tooling and standards change. For background, see the Scrum.org guide to the Definition of Done.

Definition of Done collaboration format

Quality Criteria

What quality standards must work meet to be done?

List the technical and quality checks every piece of work has to pass, such as code review, test coverage, performance and coding standards. Ask "What would make us confident this won't break in production?" to bring unwritten expectations into the open and make them measurable.

Documentation & Communication

What needs to be documented or shared before done?

Cover what needs writing down, or telling people, before work counts as done. Ask who needs to know about a change and what should exist afterward. Teams often skip this part, so ask about past gaps.

Testing & Validation

How do we verify the work actually works?

Agree the checks that prove the work does what it should. Go beyond automated tests to manual, exploratory and acceptance testing, and decide who signs off and in which environment.

Deployment & Readiness

What must be true to safely release the work?

Define what has to be true before work goes live. Talk about deployment, monitoring, rollback plans and who supports it once it's out. This closes the gap between code that's finished and a feature people can actually use.

When to use this retrospective

  • When a new team is forming and needs to agree on quality standards from the start.
  • When work keeps getting reopened or bugs are reaching production, which usually means people disagree on what finished looks like.
  • Before a new project starts, so the team agrees on the bar before work begins.
  • When onboarding new members who need to learn the team's quality expectations.
  • When a retrospective shows that people on the team treat completion differently.

Suggested icebreaker questions

  • If 'done' had a personality, what would it be like: perfectionist, pragmatist or last-minute hero?
  • What's the most surprising thing you once discovered wasn't actually finished?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Build the Definition of Done with the whole team so everyone owns it. Don't let one person write it alone.
  • Keep the criteria realistic. A DoD the team never meets gets ignored.
  • Make each criterion specific enough to check, so there's no argument about whether it's been met.
  • Revisit it every few sprints as your standards and tooling change.
  • Give everyone time to add ideas on their own before the group discussion, so quieter people contribute.
  • Keep it separate from acceptance criteria. The DoD applies to all work, while acceptance criteria belong to one story.

Frequently asked questions

What is a Definition of Done in agile?
It's a shared list of criteria every piece of work has to meet before the team calls it complete. It gives everyone the same quality bar and ends arguments about what finished means.
How is the Definition of Done different from acceptance criteria?
The Definition of Done applies to every work item. Acceptance criteria belong to one user story and describe what that story has to do. Work is complete only when it meets both.
Who should be involved in creating the Definition of Done?
The whole team, including developers, testers, designers and the product owner. People follow a standard they helped write, and each role knows what tends to get skipped in its area.
How often should we update our Definition of Done?
Review it every few sprints, often in a retrospective, or when your tooling or skills change. Add criteria as the team becomes able to meet them.
How long does it take to create a Definition of Done?
A first session usually takes 45 to 90 minutes, depending on team size and how much the team already agrees. Later reviews are much shorter.
Ready to run this retrospective?Try this retrospective live