Most teams do not struggle because they lack a Definition of Done. They struggle because theirs sounds respectable in a workshop, then collapses under delivery pressure. Good definition of done examples are not slogans about quality. They are operational standards that remove ambiguity at the exact moment work is about to be called complete.
For Scrum Masters, Product Owners, engineering managers and Agile coaches, that distinction matters. A weak Definition of Done creates false progress, unstable increments and painful sprint reviews. A strong one gives the team a shared release standard, reduces rework and makes forecasting more credible.
What a Definition of Done actually needs to do
A Definition of Done is a shared quality bar that applies to work before the team marks it complete. It is not the same thing as acceptance criteria. Acceptance criteria are item-specific and describe what a particular story or feature must do. The Definition of Done is broader. It sets the minimum operational, technical and validation standards that every relevant backlog item must meet.
That sounds simple, but the trade-off is real. If the definition is too light, the team ships debt and hidden risk. If it is too heavy, flow slows down and every item gets trapped in process. The right standard depends on product risk, architecture, compliance expectations, test maturity and release model.
In practice, the best definitions are specific enough to be testable and short enough to be used daily. If a team cannot apply it quickly during refinement, development and review, it will become wall decoration.
Definition of done examples for real delivery teams
The examples below are designed to show different levels of maturity and context. They are not meant to be copied blindly. Treat them as patterns to adapt.
1. Basic Scrum team Definition of Done
This is a sensible starting point for a team that needs more discipline without creating overhead.
A backlog item is done when development is complete, peer review has been completed, unit tests have passed, acceptance criteria have been met, the item has been demonstrated to the Product Owner, and no critical defects remain open.
This works because it covers build quality, functional fit and business validation. It does not try to solve every governance concern on day one. For a newer team, that restraint is useful.
2. Definition of Done for a team shipping to production every sprint
Where release frequency is high, the standard has to reflect production readiness rather than internal completion.
A backlog item is done when code is merged to the main branch, automated tests pass in the pipeline, security checks pass, documentation is updated where needed, feature flags are configured, deployment to production has completed successfully, and monitoring has been checked after release.
This is stronger than a standard Scrum example because it removes the loophole of saying work is complete while release activity still sits elsewhere. If your operating model treats releasable as done, the definition needs to enforce that.
3. Definition of Done for regulated or audit-heavy environments
Enterprise teams in financial services, health or government often need a more controlled standard.
A backlog item is done when functional and non-functional requirements are met, test evidence is recorded, peer review is signed off, traceability to requirements is maintained, security and compliance controls are completed, release notes are prepared, and audit artefacts are stored in the agreed repository.
The risk here is obvious. Teams can turn the Definition of Done into a bureaucratic gate that slows delivery to a crawl. The answer is not to remove controls. It is to automate evidence capture wherever possible and define only what is genuinely required.
4. Definition of Done for API or platform teams
Platform and API teams often struggle because visible UI validation is not the main quality signal.
A backlog item is done when contract changes are agreed, API documentation is updated, backward compatibility has been assessed, automated integration tests pass, performance impact is acceptable, observability has been added or updated, and consumers have been notified where a change affects them.
This example works because it reflects downstream dependency risk. For shared services, done is not just about local code quality. It is about system reliability and safe adoption by other teams.
5. Definition of Done for data or reporting work
Data teams are frequently judged complete once a dashboard appears, even when underlying quality is weak.
A backlog item is done when source mappings are validated, transformation logic is reviewed, data quality checks pass, business definitions are agreed, access permissions are applied, visual outputs are verified with users, and refresh behaviour is monitored after deployment.
Without these controls, reporting work often creates quiet operational damage. Numbers look polished while trust erodes.
6. Definition of Done for UX-heavy product work
Where customer experience is central, the team may need to include design quality in the standard.
A backlog item is done when the implemented design matches approved behaviour, responsive views are validated, accessibility checks are completed, content has been reviewed, analytics tracking is in place, acceptance criteria are met, and the Product Owner confirms the outcome supports the intended user journey.
This prevents the familiar failure mode where a feature is technically complete but awkward to use, poorly measured or inaccessible.
7. Definition of Done for support-heavy legacy teams
Legacy environments need realism. An idealised standard that assumes full automation will be ignored.
A backlog item is done when code changes are implemented, impact analysis is documented, regression testing is completed for affected areas, support notes are updated, rollback steps are defined, and known limitations are recorded and accepted.
This is not glamorous, but it is operationally honest. Teams working in older estates need standards they can meet consistently while they improve engineering capability over time.
8. Definition of Done for multi-team programme delivery
At programme level, local completion can still create integration pain.
A backlog item is done when team-level quality checks are complete, dependencies have been addressed, integration testing has passed in the shared environment, interface changes have been communicated, programme reporting has been updated, and there is no unresolved blocker for downstream teams.
The point here is alignment. One team calling something done means very little if the wider value stream cannot absorb it.
9. Definition of Done for defect fixes
Many teams apply one standard to all work, then quietly lower the bar for defects during a crunch.
A defect is done when the root cause has been identified, the fix has been peer reviewed, regression testing passes, related automated tests are added or updated, production support documentation is amended if necessary, and the issue is verified in the relevant environment.
This matters because rushed defect handling is a common source of repeat incidents.
Why most definitions fail in practice
The main issue is vagueness. Phrases such as tested properly, documented where necessary or approved by stakeholders sound fine until the team needs to make a call under pressure. If the wording allows three different interpretations, it will.
The second issue is mixing aspiration with current capability. Teams often write definitions based on what a mature engineering organisation should do, not what they can do reliably now. That creates habitual exceptions, and habitual exceptions destroy the standard.
The third issue is ownership. A Definition of Done should be shared, but it still needs active maintenance. If nobody reviews it after escaped defects, release failures or repeated carry-over, it becomes stale. Strong teams inspect it like any other operating policy.
How to build a Definition of Done that sticks
Start from failure points, not theory. Look at the last few items that were marked complete but caused trouble later. You will usually find recurring gaps around testing, review quality, environments, documentation, security checks or business validation. Those gaps are your raw material.
Then separate universal standards from item-specific conditions. Keep the Definition of Done focused on what should apply every time. Put story-level detail into acceptance criteria. This distinction reduces clutter and makes both artefacts more useful.
Finally, test the definition against actual workflow. Can the team verify each statement objectively? Is there a clear point in the process where the check happens? Can evidence be captured with minimal friction? If not, the wording needs work.
A practical rule is this: every line should answer the question, how would we know this is true? If the answer is vague, the standard is weak.
Keep it strict enough to matter, light enough to use
A Definition of Done is not there to impress auditors, coaches or leadership decks. It exists to protect delivery quality at team speed. That means the best definition is rarely the longest one. It is the one your team can apply consistently, challenge confidently and improve with evidence.
If you want better sprint outcomes, fewer awkward review conversations and less hidden rework, start with the standard that governs the word done. Tighten it where risk is real. Simplify it where process has become theatre. The teams that get this right usually do not sound dramatic about it. They just deliver with fewer surprises.