Definition of Done

What it is

The Definition of Done (DoD) is one of the three formal commitments in Scrum, alongside the Product Goal and the Sprint Goal. It is a universal quality standard that applies to every Product Backlog item.

• It is not the same as Acceptance Criteria. Acceptance Criteria are specific to an item; the DoD applies to all items.
• A typical DoD includes: code standards met, tests passing, code review completed, integration testing performed, documentation updated, and staging deployment successful.
• When an item meets the DoD, the resulting Increment is "Done" and potentially releasable.

When to use it

The DoD is applied to every Product Backlog item the team undertakes. It should also be reviewed regularly — especially when the team learns new quality practices, adopts new tools, or discovers recurring defects that suggest a gap.

Key concepts

DoD Template Teams Can Customize

Below is a starting checklist that most teams can adopt and adapt:

Customization: Teams may add or remove items based on their context. A mobile app team might add "tested on iOS 15+" or "signed build created." A compliance-heavy team might add "security audit passed" and "accessibility scan passed."

Real Example: Payment Feature DoD

Story: "Implement Stripe payment integration for subscription renewals"

Acceptance Criteria: User can choose Stripe as payment method, card is charged, receipt is sent, failure is handled gracefully.

Definition of Done (what ALL features need): Code reviewed, tested, merged, documented.

Expanded for payment: Because this touches payment, the team adds:

• Security review completed (no plaintext cards in logs or storage)
• PCI DSS compliance verified (Stripe handles this, but team confirms setup is correct)
• Failure scenarios tested: declined card, timeout, refund flow
• Monitoring and alerting set up for failed payments
• Smoke test run on staging: real test transaction processed and refunded

Why: Payment is high-risk. A bug here costs money or trust. The baseline DoD ensures quality; the custom additions ensure payment-specific safety.

How to Use DoD in Story Acceptance

1. At sprint planning: Remind the team of the DoD. "When this story is done, it must meet all 15 criteria."
2. During development: Developers check items off as they complete them (code review, tests, deployment).
3. Before demo: Developer or QA verifies all DoD items are complete. If not, the story is not ready for the Sprint Review.
4. In the Sprint Review: Product Owner accepts items that are truly "Done" (meet the DoD and satisfy acceptance criteria). Incomplete items go back to the backlog.
5. Post-sprint: Only items that were "Done" go into the Increment and count toward velocity. This keeps velocity honest and prevents hidden technical debt.

Common pitfalls

• Confusing with Acceptance Criteria: Writing item-specific checks into the DoD bloats it and dilutes its purpose.
• Outside team mandating it: A DoD imposed without team buy-in is ignored or gamed. The team must own it.
• Setting the bar too high: If "Done" requires perfection, the team will either miss sprints or fake compliance.
• Setting the bar too low: If "Done" means "merged to main" with no testing, quality will collapse.
• Treating it as static: A DoD that never changes signals a team that has stopped improving.
• Not enforcing it: A DoD that is not checked against every story becomes decoration. Enforce it in sprint reviews.

NZ context

In New Zealand, government and regulated industries often require the DoD to incorporate compliance checks that go beyond typical commercial software. This can include audit trails, records-management integration, privacy impact assessments, and WCAG 2.1 accessibility conformance. Teams working in these sectors should treat compliance as a first-class citizen in their Definition of Done, not an afterthought.

Career level guidance