Written by the Developers, understood by the Product Owner, facilitated — not dictated — by the Scrum Master.
If an item does not meet every line below, it is not Done. It cannot be shown at the Sprint Review, and it returns to the Product Backlog.
There is no partial credit.
The standard
This is Beauty Spot's, not a template. Copy it as a starting point and then change it — the value is in the argument your team has about each line, not in the lines themselves.
- Code quality and development practice
- Committed to the main branch
- Follows team coding standards
- Peer-reviewed by at least one other developer
- Unit tests written and passing at the agreed coverage
- Integration tests passing
- No new critical issues from static analysis
- Testing and verification
- All acceptance criteria met and verified
- Tested on target platforms and devices
- Exploratory testing completed
- No unresolved major bugs tied to this item
- Performance benchmarks met where relevant
- API response times for key endpoints meet the performance target under expected load
- Documentation and knowledge sharing
- User-facing help text updated
- Technical documentation updated, including API specs and design decisions
- Knowledge shared through a demo or a walkthrough
- Deployment and release readiness
- Deployed to the staging environment
- Meets the release criteria for production
- Beauty Spot specifics
- Flutter UI matches the approved mockups
- Backend endpoints documented in Swagger
- Key UI components reviewed for basic usability with the Product Owner
- PO reviews and accepts functionality
How this one was written
Not from a template. From three questions:
- When you build a feature, what steps make you confident it's high quality and genuinely finished?
- What quality standards would give you the confidence to release an Increment to real users?
- What has gone wrong on past projects that a clear “done” checklist would have prevented?
That third question did most of the work. People are vague about quality in the abstract and remarkably specific about the thing that burned them two years ago.
The team agreed the standard had to be three things: achievable for how they actually work, aspirational enough to push slightly beyond current habit, and flexible, designed to evolve as they matured.
Definition of Done vs acceptance criteria
These get confused constantly, and the confusion is expensive — it produces teams who think meeting the criteria means the work is finished.
| Definition of Done | Acceptance criteria | |
|---|---|---|
| Scope | The same for every item | Different for every item |
| Answers | Is our work up to standard? | Does this item do what was asked? |
| Owned by | Developers | Product Owner, refined with the team |
“All acceptance criteria met and verified” is a line inside the Definition of Done. The DoD asks whether you built it well. The criteria ask whether you built the right thing.
One line here is not Scrum's
“PO reviews and accepts functionality” is a practice choice, not framework. Strictly, the Definition of Done is the Developers' quality standard, and Product Owner acceptance is not part of it.
It's included here because it keeps the Product Owner engaged with the detail, and tells developers their work was actually seen by the person accountable for value.
But it has a cost.
It makes the team dependent on one person's availability — a Product Owner on holiday can now block “Done”. Some teams should not do this.
Decide knowingly before copying it.
This standard is alive
A Definition of Done that never changes is one nobody is using. This one gets inspected and adapted in the Retrospective.
SPRINT 3 RETROSPECTIVE
Added to "Testing and verification":
"API response times for key endpoints must meet the
performance target under expected load."
Raised by a developer who noticed response times were
inconsistent. Nothing was broken; it was just uneven, in a way
that bothered her.
That single line caught performance problems while they were
still small enough to fix in an afternoon.
Note where the improvement came from. Not from the Scrum
Master. Not from a standards document. From a developer who
spotted something slightly off and had a forum to raise it in.
Where it has to live
Somewhere the team sees it without going to look for it. A standard filed in a wiki nobody opens is a standard nobody uses, and the first time somebody is under pressure it will not occur to them to check.
On the Beauty Spot board it sits in a list of its own, at the far left, outside the workflow — because it isn't a stage. It governs all of them.
The companion standard
The Definition of Done is what the team is held to. The Definition of Ready is what an item has to satisfy before it enters a Sprint — and it is far more contested. Worth reading the argument against it before adopting one.