The Definition of Done in agile is the shared agreement between developers, testers, and product owners about what "finished" actually means. Without it, teams ship half-built features and argue about whether something's ready for production. A strong DoD works the other way. It speeds delivery up by preventing rework, catching bugs before they escape into production, and closing the gap on "wait, I thought we tested that."
The Definition of Done is a documented agreement that describes the quality baseline every user story, sprint, or release must meet before it counts as complete.
Acceptance criteria define what one feature must do. The DoD applies to all work and covers code review, automated tests, documentation, and deployment standards.
DoD operates at multiple levels in agile. Story-level covers code quality and testing. Sprint-level adds integration checks. Release-level adds security audits, performance testing, and production readiness.
Start with DoD criteria your team can actually hit today, then evolve it quarterly based on production incidents, bottlenecks, and new testing capabilities.
A strong DoD prevents scope creep during testing, reduces escaped defects, speeds up release cycles, and keeps automated coverage non-negotiable instead of skipped under deadline pressure.
Most teams debate quality standards during crunch time instead of defining them upfront. A clear DoD removes that ambiguity before it reaches production. Here’s how to build one that fits your team’s reality.
What Is the Definition of Done in Agile?
The definition of done is a documented agreement describing the conditions a product increment must meet before the team calls it complete. It covers the technical, quality, and documentation standards that need to be true before something counts as done, not just whether the code compiles or looks right in staging.
The dod in agile usually lives in your project management tool, wiki, or test management platform like aqua cloud, where it stays visible to developers, testers, product owners, and stakeholders. When someone asks “is this done?”, the DoD answers without debate.
Acceptance criteria and the DoD solve different problems. Acceptance criteria are specific to one user story and define what that feature needs to do. A login feature might need “users can authenticate with email and password.” The DoD sits above that. It applies to every story, sprint, and release, and adds requirements like unit tests written, security review passed, and documentation updated. Acceptance criteria confirm the feature works. The DoD confirms it was built to a consistent standard.
Scrum treats what is definition of done in agile as a core practice, describing it as the formal state an increment must reach to meet the product’s quality bar. Teams running Scaled Agile Framework (SAFe) will hit the safe definition of done at team, program, and solution levels, each one building on the last so quality holds up across a bigger organization. Teams without a clear agile dod tend to accumulate technical debt and spend release retrospectives arguing about what “ready” means instead of shipping.
Why the DoD Matters in Software Testing
A weak or missing definition of done creates chaos for QA. Here’s why a solid DoD matters for agile software testing:
Prevents scope creep during testing – Without a DoD, developers hand off features in a vague state. Testers find missing unit tests or broken staging builds instead of doing actual QA work, and stories bounce back to development more often than they should.
Sets a consistent quality gate – When everyone knows the bar, testing gets predictable. Testers spend time on exploratory testing and edge cases instead of catching issues that should’ve been caught before handoff.
Reduces escaped defects – Teams that enforce their DoD ship fewer bugs to production, because the DoD catches the usual gaps: missing tests, skipped code reviews, forgotten security checks.
Speeds up release cycles – Sounds backwards, but a strong DoD gets features to production-ready state faster. You catch problems early instead of discovering them late in the cycle.
Improves traceability – A good DoD includes documentation requirements, so when a bug shows up six months later, your team can trace it back to the original requirement and test. Platforms like aqua cloud connect test cases, executions, and defects to specific requirements automatically.
Aligns manual and automated testing – The DoD sets the required level of automated coverage, so nobody argues about whether a feature needs unit tests or end-to-end checks, and automated tests don’t quietly become optional when deadlines get tight.
Testing without a DoD is like grading without a rubric. You spend time debating subjective standards instead of catching real issues.
When you’re building your Definition of Done, one of the biggest challenges is enforcing it consistently across sprints without creating bottlenecks. That’s where a purpose-built test management platform like aqua cloud becomes invaluable. aqua provides the infrastructure to turn your DoD from a wiki document into an actionable quality contract with requirement-to-test traceability, reusable test case templates, and real-time coverage dashboards that show exactly which DoD criteria have been met for each story. What makes aqua particularly powerful for agile teams is its domain-trained AI (aqua Intelligence) with RAG grounding, which learns from your project’s own requirements and documentation to generate test cases, user stories, and test data in seconds. All of them are contextually aligned with your specific product and quality standards. Instead of debating whether something meets your DoD, you can see it clearly: code reviewed, tests executed and passing, documentation updated, deployed to staging; all tracked and verified in one place with full audit trails.
Enforce your Definition of Done with 100% traceability and AI-powered test generation
A strong dod checklist in agile should be specific enough to guide decisions but flexible enough to apply across different work. Most include:
Code quality standards – Code follows team conventions, passes linting, and stays under agreed complexity thresholds.
Automated test coverage – Unit, API, and integration tests are written and passing, often against a coverage percentage or a critical-path requirement.
Code review approval – At least one other developer has reviewed and approved the change. High-risk changes like auth logic or database migrations often need two.
Manual testing completion – For features needing exploratory or manual validation, the DoD specifies which test cases must run and pass. A test management platform tracks who ran what and what came back.
Documentation updated – READMEs, API docs, and internal wikis reflect the new functionality, which cuts down on knowledge silos.
Acceptance criteria met – The feature satisfies everything defined in the user story. Worth stating explicitly, since “the code compiles” isn’t the same as “done.”
Deployed to staging – The feature runs in a non-production environment that mirrors production closely enough to catch environment-specific issues.
No known critical defects – Minor bugs might be acceptable depending on risk. Critical or high-severity ones block completion, and severity levels should be defined clearly so nobody argues about it.
Security and compliance checks passed – Depending on your domain, this might mean penetration testing, GDPR review, or an accessibility audit with a tool like axe-core.
Performance testing completed – For performance-sensitive features, this might mean smoke tests with a tool like Grafana k6 to confirm the change doesn’t degrade response times.
None of this is universal. An MVP-stage startup might stick to automated tests and basic docs. A regulated enterprise team might add formal sign-offs and disaster recovery tests. Your definition of done template should match your actual quality needs, not an idealized version of them.
DoD at Different Levels in Agile
The definition of done isn’t one checklist for everything. It scales with the size of the work:
Story-level DoD – The most common level. Covers code quality, automated tests, manual validation, documentation, and deployment to a test environment. A story isn’t done until it clears this bar.
Sprint-level DoD – Confirms the sprint increment as a whole is shippable. Adds integration testing, regression runs, release notes, and a stakeholder demo on top of the story-level bar.
Release-level DoD – Expands again before shipping to production: performance testing, security audits, compliance sign-off, rollback plans, and monitoring setup. This is where governance and risk management live.
Feature-level DoD – Some teams add a separate DoD for large features or epics spanning multiple sprints, covering things like training materials, support prep, and analytics instrumentation.
In SAFe environments, the safe definition of done extends to program and solution levels, adding cross-team integration testing or regulatory certification depending on scope. Each level builds on the one below it. A sprint can’t be done if its stories aren’t. A release can’t be done if the sprint isn’t. Teams usually document these levels in their test management platform so everyone knows which standard applies when. aqua cloud, for example, lets teams build templates and checklists per level and track completion across releases.
How to Create a Definition of Done for Your Team
You can’t just copy another team’s wiki page. A DoD needs to match your stack, your team’s maturity, and your product’s risk profile.
Start with your current reality – Don’t write an aspirational DoD requiring practices you don’t have yet. If you have no unit tests today, don’t put 80% coverage in tomorrow’s DoD. Document what you already do and use that as the baseline.
Involve the whole team – Product owners, engineers, QA, and DevOps should all weigh in. Run a workshop where everyone says what “done” means to them. You’ll surface gaps fast, like a developer thinking staging deployment counts as done while a tester expects production-level validation.
Identify your highest risks – What breaks most in production? If authentication bugs keep showing up, require security testing for auth changes. Your DoD should target your actual pain points.
Define measurable criteria – “Code is high quality” tells nobody anything. “Code passes linting with zero errors” does. Specificity is what makes a DoD enforceable.
Document it somewhere shared – Put it in your project tool, wiki, or test management platform, somewhere nobody has to hunt for it.
Review it regularly – Schedule a quarterly check on whether the DoD is still right. Too lenient and issues slip through. Too strict and it creates bottlenecks. Adjust based on retrospectives and incident reports.
Start small and add over time – If you’ve never had a DoD, don’t roll out 20 items at once. Start with three to five, like code reviewed, tests passing, deployed to staging, then build from there.
Who creates the definition of done? The whole Scrum team, in theory. In practice, developers usually draft the first version, QA refines the testing requirements, the product owner adds acceptance criteria, and the Scrum Master runs the discussion. Nobody owns it alone, but everyone’s accountable for following it. Understanding who defines dod in agile matters here: the team collectively owns the final version, even when individual roles shape different parts of it. Larger organizations sometimes set enterprise-level minimums, and teams can add stricter requirements on top but can’t drop the mandatory ones. Teams scaling this across departments often lean on frameworks built for enterprise agile software testing to keep the DoD consistent without slowing every team down.
Definition of Done Checklist Examples
Seeing real definition of done examples makes the concept concrete. Here are four, built for different contexts.
Early-stage startup (MVP focus)
Code committed to main, one developer review, unit tests for new business logic, manual validation in staging, basic README documentation, and a verified staging deployment. Light on process, but it covers code review, some automated coverage, and manual validation. Fits a team of five to eight moving fast.
Growing SaaS product (scaling quality)
Static analysis passing, 70% test coverage on critical paths, peer code review, documented manual test execution, product owner sign-off on acceptance criteria, a clean security scan, updated documentation, QA-validated staging deployment, zero critical defects, and drafted release notes. This is a team formalizing process as its customer base grows.
Regulated fintech product (compliance-heavy)
Two-developer review including a senior engineer, a full automated suite passing, security team review, a compliance audit like PCI-DSS or SOC 2, documented regression testing, signed-off user acceptance testing, resolved or risk-assessed defects, performance testing against SLA thresholds, a tested rollback plan, an audit trail, release manager approval, and configured production monitoring. This is a heavyweight DoD for a heavyweight risk profile. Teams testing user-facing flows this closely often rely on solid UAT tools for agile teams to keep the sign-off process organized.
Mobile-first consumer app (cross-platform focus)
Merged code passing CI, unit tests on relevant platforms, validation on real iOS and Android devices, automated UI tests on critical flows, a build pushed to TestFlight or Firebase, manual exploratory testing on priority devices, accessibility checks with VoiceOver and TalkBack, updated App Store metadata, instrumented crash reporting, and prepared release notes.
None of these definition of done template examples should be copied verbatim. They’re starting points. Your DoD should reflect your product, team size, and risk tolerance. The best one is the one your team can consistently meet without cutting corners.
How to Evolve Your DoD Over Time
Your DoD shouldn’t stay static. Treat it as a living document and review it at the end of each quarter or after major releases. Ask what’s working, what’s causing bottlenecks, and whether you’re actually meeting it or quietly skipping items under pressure.
Let production incidents drive updates. If bugs keep tracing back to missing performance tests or weak security review, that’s your DoD telling you where the gap is. If a database migration caused an outage because it skipped staging validation, add explicit staging requirements for schema changes.
Fold in new practices as your team adopts them. Start using contract testing with Pact, add it to the checklist. Add BrowserStack, specify which browser combinations are mandatory. Don’t add anything your team can’t actually deliver yet. If nobody knows how to write performance tests, make that a training goal first and add it to the DoD once the skill exists.
Watch for a DoD that’s grown too heavy. If stories keep stalling on criteria that don’t add real value, cut them. Maybe you don’t need two reviewers for every change. Maybe the regression suite runs weekly instead of on every story. The goal is quality without grinding delivery to a halt.
As your team grows, consider splitting the DoD across levels: lean requirements at the story level, broader validation at sprint and release boundaries. A test management platform makes this easier to enforce consistently across the team.
Your Definition of Done is only as strong as your ability to verify and enforce it consistently. Without the right tooling, even the best-crafted DoD becomes another checkbox exercise that teams skip under pressure. aqua cloud solves this by providing end-to-end traceability from requirements through test execution, ensuring that every DoD criterion, whether it’s automated test coverage, manual validation, documentation updates, or acceptance criteria sign-off, is tracked, verified, and auditable. With aqua’s built-in agile workflows, Scrum boards, and seamless two-way Jira integration, your DoD lives where your team actually works, not buried in a wiki page. And here’s the game-changer: aqua Intelligence (AI), powered by domain-trained RAG technology, generates comprehensive test cases directly from your requirements in seconds, grounded in your project’s actual context and documentation. This means when your DoD requires “automated test coverage for critical paths, you’re generating intelligent, project-specific test cases that understand your product.
Transform your DoD from a document into an enforceable quality system with aqua
The definition of done isn’t paperwork. It’s your team’s agreement on what quality actually looks like, and when it’s specific and consistently enforced, it prevents rework and keeps everyone aligned. When it’s vague or ignored, it’s just another doc nobody opens. Start with the basics: code review, automated tests, manual validation, staging deployment. Build from there as your practices mature, and keep revisiting it as your product and risks change. Get this right and you ship better software with fewer fires to put out later.
What is the difference between the Definition of Done and acceptance criteria?
Acceptance criteria apply to one user story and describe what that feature must do. A login story might need “user can log in with email and password” and “error message shows on invalid credentials.” The definition of done applies to every story, sprint, and release, covering code review, automated tests, documentation, and deployment regardless of what the feature does. Acceptance criteria confirm the feature works. The DoD confirms it was built to a consistent standard.
Who is responsible for creating and maintaining the Definition of Done?
The whole Scrum team, formally. In practice, developers usually draft the first version based on technical standards, the product owner adds business context, and the Scrum Master facilitates and keeps it visible. QA typically drives the testing criteria. Someone often owns the documentation day to day, often a lead engineer or Scrum Master, but the team as a whole has to follow it for it to work. Larger organizations running SAFe may layer team-specific criteria on top of enterprise-wide minimums.
How detailed should a Definition of Done be?
Detailed enough to remove ambiguity, not so detailed it becomes bureaucratic. Three vague items like “code is good” won’t help anyone. Forty micro-tasks will get ignored under deadline pressure. Aim for five to fifteen clear, measurable criteria at the story level, each one answering “how do we know this is true?” A small startup might run a lean five-item DoD. A regulated enterprise product might need a longer checklist with formal approvals. Start lean, check whether it’s catching real issues, and adjust from there.
Nurlan, a QA Coordinator & Quality Standards Officer, takes pride in orchestrating seamless QA operations. His expertise in coordinating QA-focused projects and integrating QA solutions has consistently yielded top-tier client satisfaction. Aside from a full-time QA coordinator, Nurlan's role involves creating compelling content that educates…
Justina's expertise in QA reporting and automation makes her a vital force behind data-driven quality assurance at aqua. As a specialist, Justyna has played a key role in designing scalable automation frameworks and insightful reporting systems that empower aqua's Customers to track, measure, and optimize…
Join our community of enthusiastic experts! Get new posts from the aqua blog directly in your inbox. QA trends, community discussion overviews, insightful tips — you’ll love it!
We're committed to your privacy. Aqua uses the information you provide to us to contact you about our relevant content, products, and services. You may unsubscribe from these communications at any time. For more information, check out our Privacy policy.
X
🤖 Exciting new updates to aqua AI Assistant are now available! 🎉
