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.