Senior engineer insight
Teams that consistently deliver on their Definition of Done treat it as a living contract, not a wall poster — they genuinely halt sprint reviews when an item is incomplete, even under stakeholder pressure. What separates high-performing NZ agile teams from the rest is that their DoD grows through retrospectives driven by real production data: a performance regression that slipped through prompts an LCP threshold being added; an accessibility complaint from a screen-reader user at Revenue NZ adds a WCAG 2.1 AA scan gate. The single pattern that actually works is making every DoD criterion binary and visible on-screen during the sprint review so that omission is physically awkward, not just theoretically wrong.
The most common mistake teams make when adopting Definition of Done: they write a comprehensive checklist on day one, then never revisit it — so it either becomes so aspirational that teams quietly skip items, or so stale that it no longer reflects how the team actually ships.
From the field
A Wellington digital agency building a KiwiSaver dashboard for a mid-tier fund manager ran nine successful sprints with a DoD that included “staging deployment successful” — but nobody had formally defined what “successful” meant. The team assumed it meant the build passed; the test lead assumed it meant a smoke-test sign-off; the Product Owner assumed it meant feature-complete and visually correct on mobile. In sprint ten, a rounding error in unit-price calculations slipped through to UAT because each person’s interpretation of “successful” let the others assume someone else had caught it. The team rewrote the DoD to replace every ambiguous item with a specific, named check — “smoke test suite passes on Chrome, Safari, and mobile emulator” — and assigned a rotating DoD guardian each sprint. The lesson that sticks beyond that team: a DoD criterion that two people can interpret differently is not a criterion; it is a gap waiting to become an incident.
Definition of Done
A shared, formal commitment that defines the quality criteria all Product Backlog items must meet to be considered complete and potentially releasable.
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
| Concept | What it means |
|---|---|
| DoD vs Acceptance Criteria | The DoD is a global quality gate; Acceptance Criteria are item-specific functional conditions. Both must be satisfied. |
| Potentially Releasable | "Done" means the Increment could be released to production immediately. It does not mean it will be — only that it could be. |
| Evolving Standard | The DoD should improve over time as the team matures. Adding regression automation or performance checks are common evolutions. |
| Organisational Baseline | Organisations may set a minimum DoD (e.g., security scan passed). Teams can add to it, but cannot drop below it. |
DoD Template Teams Can Customise
Below is a starting checklist that most teams can adopt and adapt:
Definition of Done Checklist
- [ ] Code written and peer-reviewed (at least one approval)
- [ ] Acceptance criteria met and verified
- [ ] Unit tests written and passing (minimum 80% code coverage)
- [ ] Integration tests passing
- [ ] No console errors or warnings in browser DevTools
- [ ] Code merged to main branch
- [ ] Tested on at least two browsers (Chrome, Firefox, Safari, or Edge)
- [ ] Tested on mobile device (iOS and Android, or emulator)
- [ ] Documentation updated (README, API docs, user guide if applicable)
- [ ] Database migrations run cleanly (if applicable)
- [ ] Performance checked (no new slow queries, no image > 200KB, LCP < 3s)
- [ ] Security review passed (no hardcoded secrets, input validation applied)
- [ ] Staging deployment successful
- [ ] Product Owner approval received
- [ ] Ready for production release (no blockers)
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
- At sprint planning: Remind the team of the DoD. "When this story is done, it must meet all 15 criteria."
- During development: Developers check items off as they complete them (code review, tests, deployment).
- Before demo: Developer or QA verifies all DoD items are complete. If not, the story is not ready for the Sprint Review.
- 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.
- 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
| Level | Focus |
|---|---|
| Grad | Learn the team's DoD by heart. Apply it to every task you pick up. Ask questions if a criterion is unclear. |
| Junior | Ensure your Product Backlog items meet the DoD before handoff. Do not declare an item "Done" until every checkbox is ticked. |
| Senior | Contribute to evolving the DoD based on lessons learned. Mentor juniors on quality practices and challenge shortcuts. |
| Test Lead | Ensure testing criteria in the DoD are explicit, measurable, and enforced. Advocate for including non-functional requirements and compliance checks. |
Industry Reality
- DoDs are often aspirational, not enforced. Many teams have a Definition of Done posted on a wall or wiki page that nobody checks at sprint review. In practice, Product Owners accept stories based on a demo, not a systematic checklist review.
- Pressure compresses quality gates. When sprint deadlines loom, "we'll add the tests next sprint" becomes a recurring phrase. Senior practitioners push back explicitly — incomplete DoD items go back to the backlog, full stop.
- The DoD gets organisationally imposed more often than team-owned. Textbook Scrum says the team writes the DoD; real workplaces often have security, compliance, or architecture teams mandate additions. Experienced testers treat these additions as non-negotiable floors, not optional suggestions.
- Multiple DoD tiers emerge in scaled environments. On multi-team products (SAFe or LeSS contexts common in NZ government and banking), there is a team-level DoD and a program-level DoD. Items must satisfy both before they can contribute to a release.
- DoD drift is real. Teams that were diligent in year one quietly remove items ("we don't need to check accessibility every sprint") as friction builds. Periodic DoD retrospectives — at least quarterly — are the practical defence against this erosion.
Context guide
How the right level of Definition of Done effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government digital services (Revenue NZ, Benefits NZ, LandNZ) | Essential | Privacy Act 2020 obligations, mandatory WCAG 2.1 AA conformance under the NZ Government Web Accessibility Standard, and OIA disclosure risk mean every story must meet a compliance floor before release. |
| Regulated financial services (Harbour Bank, Pacific Bank, KiwiSaver providers) | Essential | RBNZ prudential requirements and FMA conduct obligations mean the DoD must include audit-trail verification and security scan gates. Incomplete increments expose the organisation to regulatory sanction, not just technical debt. |
| Health technology (HealthNZ / HealthNZ, CoverNZ systems) | Essential | Health Information Privacy Code and HISO standards require a DoD that includes data-handling verification and clinical data integrity checks. Errors at the increment level propagate to patient safety outcomes. |
| Commercial SaaS startups (Wellington / Auckland tech sector) | Medium | Speed-to-market pressure makes a lean DoD (code review, CI passing, smoke test) appropriate in early stages. Add performance and security gates as the customer base grows and churn risk from defects rises. |
| Internal tooling for small operational teams | Low | Low traffic and narrow user base reduce blast radius. A minimal DoD (code review, basic smoke test) is proportionate — but do not drop accessibility checks if the tool is used by staff, as Public Service Act obligations still apply. |
| Multi-team scaled delivery (SAFe / LeSS programmes at NZ Police, FamiliesNZ) | Essential | Integration between teams means a weak DoD on one team creates defect debt that blocks every other team's release. Programme-level DoD criteria (end-to-end regression, performance baseline) must be defined centrally and enforced consistently. |
Trade-offs
What you gain and what you give up when you adopt Definition of Done.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Eliminates “definition of done” arguments. The team and stakeholders share one explicit standard, so sprint review acceptance is objective, not negotiated story-by-story. | Upfront investment in agreement. Reaching genuine team consensus on a DoD takes time, and organisations that impose it top-down often get compliance theatre rather than real quality culture. | The team is in genuine discovery mode (spike or proof-of-concept work) where the goal is learning, not shippable software. Apply a lighter “spike DoD” — readable code, key findings documented — rather than the full production standard. |
| Surfaces technical debt early. Defects and gaps caught at the DoD gate cost a fraction of the rework required after release, especially in regulated NZ environments where post-release corrections require formal change-management documentation. | Can throttle velocity in the short term. Teams migrating from undisciplined shipping to a rigorous DoD often see sprint velocity drop by 20–30% initially, which creates stakeholder pressure to relax the standard before the quality benefits materialise. | The team is running a time-boxed prototype for user research only, with a firm commitment to discard the code afterwards. A minimal DoD (readable, demonstrable) is appropriate — but document the throw-away intent explicitly so the code is never quietly promoted to production. |
| Builds team accountability. A shared DoD makes quality everyone’s job rather than a handoff responsibility. Developers, QA, and ops all contribute to criteria, which reduces silo-based finger-pointing after production incidents. | Risk of criteria becoming stale or performative. Without regular retrospective review, a DoD accumulates criteria the team ticks without genuinely performing — “documentation updated” becomes a one-line README edit nobody reads. | The team operates under a Kanban flow model with no sprint cadence. Use explicit “exit criteria per work item” rather than a sprint-cycle DoD, applied at the point of promotion between board columns rather than at a fixed ceremony. |
| Keeps velocity honest. Only fully Done items count toward sprint velocity, preventing the common dysfunction where teams report 100% story-point completion while carrying a growing backlog of “almost done” work that silently blocks the next release. | May not account for external dependencies. If DoD criteria include third-party sign-offs (e.g., a pen-test vendor, an external security team) that operate on their own schedule, items stall at the gate through no fault of the delivery team. | Third-party dependency blocks DoD completion regularly. Restructure the criterion to be “referral submitted and artefacts ready for review” (team-controllable) rather than “sign-off received” (externally controlled), and track the external gate separately in a risk log. |
Enterprise reality
How Definition of Done changes at 200–300-developer scale in NZ enterprise — banks, government, telcos
- DoD compliance is automated, not human-checked — at Pacific Bank, every pull request is gated by a CI/CD pipeline that blocks merge unless unit tests pass, a SAST scan returns zero high-severity findings, and code coverage stays above the configured threshold; a human cannot approve a story without the pipeline going green first.
- Governance and audit obligations force a programme-level DoD on top of team-level DoDs — the Privacy Act 2020 and NZISM (New Zealand Information Security Manual) require that any change touching personally identifiable information must include a privacy impact assessment sign-off and encryption verification before it can be counted as Done, regardless of what the individual squad's checklist says.
- Volume is handled by tooling, not manual discipline — organisations running SAFe across 15+ squads (common at TechServNZ and Revenue NZ) enforce DoD through Jira Automation rules and Azure DevOps branch policies, so a story cannot transition to "Done" in the backlog tool unless each linked test case shows a pass status; the DoD is embedded in the workflow engine, not in a wiki page.
- Cross-squad and cross-timezone coordination creates a new failure mode unknown to small teams — when 12 squads share a release train and three squads are based in Manila or Melbourne, a weak DoD on one squad's component causes integration failures that block every other squad's release; the cost of one squad skipping regression testing at sprint end is routinely measured in days of blocked delivery across the programme, not hours of rework for one team.
◆ What I would do
Professional judgment — when to adopt Definition of Done, when to adapt it, and what to watch for.
The bottom line: A Definition of Done is only as strong as the team’s willingness to enforce it when it is inconvenient — and in NZ regulated environments, the moment you waive it once under pressure is the moment it stops being a quality gate and starts being a suggestion.
Best Practices
- ✓ Keep the DoD visible during sprint reviews — display it on screen so the team literally ticks off each criterion before acceptance, not from memory.
- ✓ Keep it short enough to be real. A DoD with 25+ items becomes background noise. Aim for 10–15 high-signal criteria that genuinely block release if missed.
- ✓ Make each criterion binary. "Code reviewed" is verifiable; "code quality is good" is not. Every DoD item should have a clear yes/no answer.
- ✓ Separate the DoD from Acceptance Criteria in tooling. In Jira or Azure DevOps, link the DoD as a team-level template; keep item-specific acceptance criteria on the individual ticket so neither gets confused with the other.
- ✓ Assign a DoD guardian each sprint. Rotate a team member whose job it is to raise a hand if something is declared Done without meeting every criterion — this prevents groupthink acceptance.
- ✓ Evolve the DoD through retrospectives, not ad hoc. When a recurring defect type surfaces, add a DoD item in the next retrospective, not mid-sprint, to avoid scope creep and team friction.
- ✓ Include non-functional requirements explicitly. Performance thresholds, security scan gates, and accessibility checks belong in the DoD — not just functional correctness. NZ government agencies must include WCAG 2.1 AA as a standing criterion.
- ✓ Never let incomplete items linger as "90% done." There is no partial Done in Scrum. An item either meets the full DoD or it returns to the backlog and is not counted in velocity.
Common Misconceptions
❌ Myth: The Definition of Done and Acceptance Criteria are the same thing.
Reality: Acceptance Criteria are specific to a single Product Backlog item — they describe what the feature must do to satisfy the user story. The Definition of Done is a universal quality checklist that applies to every item the team produces. A story must satisfy both: its own Acceptance Criteria and all items in the DoD. Confusing them leads to stories that technically "work" but are shipped with no tests, no documentation, and no code review.
❌ Myth: The Definition of Done is set once during team formation and then stays fixed.
Reality: The Scrum Guide explicitly describes the DoD as a living commitment that the team inspects and adapts over time. As the team matures — adopting automated regression suites, adding accessibility tools, or learning from production incidents — the DoD should grow to reflect those improvements. A DoD that has not changed in six months usually signals a team that has stopped learning.
❌ Myth: "Done" means the Product Owner approved it in the Sprint Review.
Reality: Product Owner approval is one step in the process, not the definition of Done. An item is Done when it meets every criterion in the DoD — code reviewed, tests passing, integrated, documented, and deployable. If the Product Owner approves a story that skips code review and has no automated tests, the team has not shipped a Done increment; they have shipped undocumented risk. The DoD protects the team and the organisation from precisely that outcome.
Why teams fail here
- Treating the DoD as negotiable under sprint pressure — “we’ll do the tests next sprint” is the single most common phrase that precedes a production incident. Once the team accepts one exception, every subsequent exception feels justified.
- Letting the DoD be imposed top-down without team ownership — a checklist mandated by a PMO or architecture board that the team had no hand in writing is treated as bureaucracy to be tolerated, not a quality standard to be proud of. Teams game or ignore criteria they did not help create.
- Conflating DoD compliance with Product Owner approval — sprint review demos can look convincing while integration tests are still failing, documentation is missing, and the staging environment has a hard-coded secret. PO approval is a business check, not a technical quality gate; the DoD is the technical gate, and it cannot be waived by stakeholder enthusiasm.
- DoD drift through selective erosion — teams in NZ government and regulated sectors often start strong, then quietly drop accessibility checks and security scan gates as delivery pressure builds. Without a quarterly retrospective explicitly reviewing the DoD, erosion is invisible until a compliance audit or public incident makes the gap undeniable.
Key takeaway
The Definition of Done is not a quality checklist you aspire to — it is the minimum standard below which you do not ship, and its power comes entirely from the team’s willingness to enforce it when the pressure to skip it is highest.
How this has changed
The field moved. Here is how Definition of Done evolved from its origins to current practice.
In early agile teams, "done" is informally understood. Developers say code is done when it compiles; testers when tests pass; PO when users see it. Ambiguity causes endless rework and "it was done last sprint" arguments.
The Scrum Guide formalises the Definition of Done as a shared understanding of what "done" means for an increment — an explicit artefact the team owns and enforces.
The DoD matures beyond code to include unit tests, peer review, integration tests, accessibility checks, and security scanning. The DoD becomes a quality gate preventing technical debt accumulation.
Scaled agile frameworks introduce multi-level Definitions of Done — team-level, programme-level, and release-level — with different quality requirements at each level.
AI-assisted DoD verification is emerging — automated checks that verify code is reviewed, tests pass, security scans are clean, and documentation is updated. The DoD criteria grow more comprehensive as teams automate enforcement.
Self-Check
Click each question to reveal the answer.
Q1: Your team is building the Benefits NZ Work and Income online application portal. The sprint retrospective reveals that three stories in the last sprint were accepted by the Product Owner in the Sprint Review, but none had their integration tests run because the test environment was down. The team argues this still counts as Done. What is your response and what should the team do?
A: The stories are not Done. The Definition of Done is a non-negotiable quality gate — if integration tests are a criterion and they were not run, the increment is incomplete regardless of Product Owner approval. The Product Owner’s acceptance confirms the feature meets its Acceptance Criteria; it does not override the DoD. The team should move the three stories back to the Product Backlog, complete the outstanding integration testing next sprint, and raise the test-environment reliability issue in the retrospective as a systemic risk to DoD compliance.
Q2: Your scrum team works on the RealMe identity verification service used by Revenue NZ and TransitNZ. A senior developer proposes adding a mandatory penetration-test sign-off to the Definition of Done for every sprint. The Scrum Master pushes back, saying this will make the DoD impossible to meet within a two-week sprint. Who is right, and how would you resolve this?
A: Both have valid points, but the Scrum Master’s concern is about implementation, not the goal. A full penetration test every sprint is impractical, but security scrutiny on an identity service cannot be dropped from the DoD. The resolution is to make the criterion achievable: replace “penetration test sign-off” with “automated SAST/DAST scan passed with no new high or critical findings,” and schedule a formal manual penetration test quarterly or before each major release. This keeps the DoD enforceable each sprint while maintaining the security rigour required for a service that underpins government identity across NZ.
Q3: What is the key difference between the Definition of Done and Acceptance Criteria, and why does confusing them cause problems in practice?
A: Acceptance Criteria are story-specific — they describe what a particular feature must do to satisfy the user’s need (e.g., “user can upload a file up to 10 MB”). The Definition of Done is a universal quality checklist that applies to every story regardless of its content (e.g., “code reviewed, tests passing, deployed to staging, documentation updated”). Confusing them causes two failure modes: teams write story-specific checks into the DoD, making it unwieldy and inconsistent; or they satisfy the Acceptance Criteria and skip the DoD, shipping features that work functionally but have no tests, no review, and hidden technical debt. Both conditions must be satisfied independently before an item can be considered complete.
Q4: A developer tells you, “The Definition of Done slows us down — we should skip the documentation and accessibility checks for internal admin tools because only five staff will ever use them.” What is wrong with this reasoning and how do you respond?
A: This reasoning treats the DoD as negotiable based on audience size, which undermines its purpose as a consistent quality floor. In the NZ public sector, “internal” does not exempt a tool from accessibility obligations — the NZ Government Web Accessibility Standard applies to tools used by staff, particularly under the Public Service Act, and CoverNZ or HealthNZ staff with disabilities are entitled to accessible tooling. More broadly, skipping DoD items selectively erodes the team’s quality culture: if documentation and accessibility can be dropped for “small audiences,” other criteria will follow. The right response is to raise this in a retrospective and, if the team genuinely believes certain criteria are disproportionate for specific contexts, formally update the DoD through the agreed process rather than bypassing it ad hoc.