Definition of Done (DoD)

Definition of Done (DoD) is a fundamental concept in Agile and Scrum that establishes a shared understanding of what it means for work to be considered complete. Agile teams deliver software incrementally, and each increment must meet defined quality standards before it can be accepted. Definition of Done provides a clear and consistent set of criteria that ensures completed work is truly finished, tested, and ready for delivery.

Definition of Done answers an important question in Agile development: “What does ‘done’ really mean?” Without a clear Definition of Done, teams may interpret completion differently. Developers may consider coding completion as done, while testers may expect full validation and defect resolution. The Product Owner may expect a feature to be production-ready. Definition of Done removes this ambiguity by defining completion criteria that everyone agrees upon.

Definition of Done ensures that each user story or feature meets required quality standards before being accepted. It supports consistent delivery and prevents incomplete work from being marked as finished. For manual testers, Definition of Done is especially important because it ensures that testing activities are included as an essential part of completion rather than treated as an optional step.

A strong Definition of Done ensures that quality is built into the development process and verified before work is accepted.

Definition of Definition of Done

Definition of Done is a shared, agreed-upon set of criteria that determines when a user story, feature, or product increment is considered complete.

Definition of Done establishes the minimum quality requirements that must be satisfied before a backlog item can be marked as done. These requirements typically include development completion, testing completion, defect resolution, and product acceptance.

Definition of Done ensures that completed work is potentially releasable. This means that the increment produced during a sprint could be released to production if required.

Definition of Done applies consistently across all user stories within a team. Unlike Acceptance Criteria, which are specific to individual stories, Definition of Done is a team-level standard.

Definition of Done ensures that completion is measurable and verifiable. Work cannot be marked as done unless all DoD conditions are satisfied.

Purpose of Definition of Done

Definition of Done serves multiple important purposes in Agile projects.

One of the main purposes is creating a common understanding of completion. Everyone on the team understands what must be completed before a story can be considered finished.

Definition of Done ensures consistent quality standards. Every story must meet the same quality criteria.

Definition of Done prevents incomplete or partially tested work from being accepted. Stories cannot be closed without meeting required conditions.

Definition of Done supports predictable releases. When each increment meets quality standards, release decisions become easier.

Definition of Done improves accountability. Teams clearly understand their responsibilities.

Definition of Done also improves transparency. Stakeholders know what “done” means and what quality level to expect.

Importance of Definition of Done in Agile Projects

Definition of Done is essential for successful Agile delivery.

Agile teams deliver working software in short iterations. Without Definition of Done, teams may deliver partially completed features that require additional work later.

Incomplete work increases technical debt and reduces product quality.

Definition of Done ensures that work is completed fully within the sprint. This prevents unfinished tasks from accumulating.

Definition of Done improves trust between teams and stakeholders. Stakeholders know that completed features meet agreed standards.

Definition of Done also improves team discipline. Teams must complete all required activities before marking work as done.

Definition of Done helps ensure that Agile delivery remains sustainable and predictable.

Typical Definition of Done Criteria

Definition of Done criteria vary by team and organization, but certain elements are commonly included.

Acceptance criteria must be fully satisfied. The feature must behave as expected.

Functional testing must be completed. Testers must verify all required scenarios.

Regression impact must be assessed. Existing functionality must remain unaffected.

There should be no open Critical or High defects. Serious issues must be resolved before completion.

Test cases should be executed and updated. Test documentation must reflect current functionality.

Defects must be logged, tracked, and verified. Defect management must be complete.

Documentation should be updated if required. User guides or technical documents must reflect changes.

The Product Owner must accept the story. Business validation confirms completion.

These criteria ensure that stories meet both technical and business expectations.

Manual Tester’s Role in Definition of Done

Manual testers play a central role in ensuring Definition of Done is satisfied.

Testers validate Acceptance Criteria. They ensure the feature behaves according to requirements.

Testers ensure testing completeness. All required scenarios must be executed.

Testers confirm defect status. Critical defects must be resolved.

Testers provide test sign-off input. Their validation supports completion decisions.

Testers ensure that quality standards are maintained.

Testers also assess regression impact. Changes should not break existing functionality.

Testers update test cases when features change.

Testers help ensure that Definition of Done is applied consistently.

Without tester involvement, Definition of Done may not properly address quality requirements.

Definition of Done and Quality Assurance

Definition of Done is closely connected to quality assurance.

Quality cannot be achieved by testing alone. It must be built into the development process.

Definition of Done ensures that quality activities are included in every sprint.

Testing becomes part of development rather than a separate phase.

Definition of Done ensures that validation occurs before work is accepted.

Definition of Done reduces defect leakage into production.

Definition of Done also ensures that regression risks are evaluated.

Quality becomes a continuous responsibility rather than a final checkpoint.

Definition of Done vs Acceptance Criteria

Definition of Done and Acceptance Criteria are closely related but serve different purposes.

Acceptance Criteria define story-specific behavior. They describe what the feature must do.

Definition of Done defines completion requirements. It describes what must happen before the story is accepted.

Acceptance Criteria apply to individual user stories.

Definition of Done applies across the entire team.

Acceptance Criteria are used during testing.

Definition of Done is verified at story completion.

Acceptance Criteria confirm feature correctness.

Definition of Done confirms overall completion.

Both are required for successful Agile delivery.

Definition of Done vs Definition of Ready

Definition of Done and Definition of Ready represent opposite ends of the Agile workflow.

Definition of Ready ensures that work is prepared before the sprint.

Definition of Done ensures that work is completed after the sprint.

Definition of Ready focuses on readiness.

Definition of Done focuses on completion.

Definition of Ready prevents unclear stories from entering the sprint.

Definition of Done prevents incomplete stories from leaving the sprint.

Together, Definition of Ready and Definition of Done create a structured Agile workflow.

Definition of Ready ensures the team starts correctly.

Definition of Done ensures the team finishes correctly.

Real-Time Example of Definition of Done

Consider a user story involving password reset functionality.

Development may complete coding and unit testing. However, this does not mean the story is done.

Acceptance Criteria must be verified.

Functional testing must be completed.

Regression testing must confirm that login functionality still works.

All critical defects must be resolved.

Test cases must be updated.

The Product Owner must accept the feature.

Only after all these conditions are satisfied can the story be considered done.

If regression testing reveals a broken feature, the story is not done.

If a high-severity defect remains open, the story is not done.

Definition of Done ensures that incomplete work is not accepted.

Benefits of a Strong Definition of Done

A strong Definition of Done provides significant benefits.

It improves product quality because all work must meet defined standards.

It reduces rework because incomplete stories are not accepted.

It improves release readiness because increments are fully validated.

It improves team discipline because completion criteria are clear.

It improves stakeholder trust because delivered features meet expectations.

It improves testing effectiveness because testing is mandatory.

It improves predictability because teams deliver consistent increments.

Teams with strong Definition of Done practices typically produce higher-quality software.

Definition of Done in Real Agile Environments

In real Agile projects, Definition of Done evolves over time.

Teams update DoD criteria as they learn from experience.

If production defects occur frequently, teams may strengthen testing requirements.

If DoD becomes too complex, teams may simplify criteria.

Definition of Done should remain practical and achievable.

Definition of Done should reflect team maturity and project complexity.

Successful teams review Definition of Done periodically.

Definition of Done works best when applied consistently.

Common Mistakes in Definition of Done

Some teams create vague Definition of Done criteria. This leads to inconsistent interpretation.

Definition of Done should be specific and measurable.

Some teams ignore testing activities in Definition of Done. This leads to incomplete validation.

Testing must be part of Definition of Done.

Some teams change Definition of Done frequently. Frequent changes create confusion.

Definition of Done should remain stable unless improvements are necessary.

Some teams treat Definition of Done as optional. This defeats its purpose.

Definition of Done must be applied consistently.

Some teams consider coding completion as done. This leads to quality issues.

Definition of Done must include validation and acceptance.

Definition of Done and Release Readiness

Definition of Done supports release readiness decisions.

When every story meets Definition of Done, the product increment becomes potentially releasable.

Release decisions become easier and less risky.

Teams can confidently deliver increments to stakeholders.

Definition of Done reduces last-minute testing before release.

Definition of Done ensures that quality is maintained throughout development.

Release readiness becomes predictable rather than uncertain.

Why Definition of Done Matters to Agile Teams

Definition of Done matters because Agile teams work in short cycles and need a reliable way to know whether an increment is actually complete. Without DoD, completion becomes subjective. One person may say a story is done when coding is finished. Another may say it is done only after testing. A Product Owner may expect the story to be ready for release. These different interpretations create confusion, rework, and mistrust.

A shared DoD removes this confusion by making completion visible. It tells the team which activities must be completed before work can be called done. This may include code review, unit testing, functional validation, regression impact checks, defect verification, documentation updates, and Product Owner acceptance. When everyone understands these expectations upfront, the team can plan work more realistically.

Definition of Done also protects product quality from schedule pressure. In many teams, testing and cleanup activities are the first things squeezed when time is short. A strong DoD prevents this by making quality activities part of the work itself. Testing is not an optional activity performed if time remains. It is part of what completion means.

DoD is especially important when multiple people work on different stories in the same sprint. If every story follows a different completion standard, the increment becomes inconsistent. Some work may be tested thoroughly while other work is only partially verified. A common DoD gives the team a consistent quality baseline across the sprint.

For stakeholders, DoD improves trust. When the team says a story is done, stakeholders can rely on that statement because “done” has a specific meaning. This trust is essential in Agile delivery, where business users frequently inspect increments and make decisions based on the team’s reported progress.

DoD as a Quality Agreement

Definition of Done is best understood as a quality agreement within the Scrum Team. It is not simply a checklist created for reporting. It is a shared commitment to the minimum level of quality the team will maintain for every completed backlog item. This agreement helps the team avoid shortcuts that create hidden work later.

A quality agreement must be realistic. If the DoD includes activities the team cannot actually perform, it becomes ceremonial. For example, if the DoD says every story must complete full automation coverage but the team has no automation framework or capacity, the criterion will be ignored. A useful DoD should be strong enough to protect quality and practical enough to follow consistently.

At the same time, DoD should not be too weak. If the DoD only says “code completed,” it does not protect the product. It leaves testing, regression, documentation, and acceptance unclear. A weak DoD allows incomplete work to move forward and creates technical debt. The team may appear fast in the short term but slow down later because unfinished work accumulates.

A good DoD reflects the team’s current maturity while encouraging improvement. A new team may begin with a basic DoD and strengthen it over time. A mature team may include deeper quality expectations such as accessibility checks, security review for sensitive changes, performance considerations, or automation updates. The DoD should evolve with the team’s capability.

Because DoD is a quality agreement, it should be visible. Team members should be able to refer to it during planning, development, testing, and review. If it exists only in someone’s memory or an old document, it will not guide daily work. Visible DoD keeps quality expectations active throughout the sprint.

Definition of Done at Story, Sprint, and Release Levels

Definition of Done can be applied at different levels. At the story level, it defines whether an individual User Story is complete. At the sprint level, it helps determine whether the increment produced during the sprint is potentially releasable. At the release level, it supports confidence that the product is ready for deployment or stakeholder delivery.

Story-level DoD usually includes criteria such as acceptance criteria satisfied, code reviewed, unit tests passed, functional testing completed, defects resolved, test cases updated, and Product Owner acceptance received. These checks ensure that an individual story is not closed prematurely.

Sprint-level DoD focuses on the integrated increment. Even if individual stories pass, the increment must still work together. Integration issues, regression defects, configuration problems, and environment-specific failures can appear when stories are combined. The team should ensure that the sprint increment remains stable as a whole.

Release-level readiness may include additional criteria beyond the team’s DoD. For example, production deployment approval, release notes, user training, operational monitoring, security sign-off, or business go-live approval may be required. These release checks may not apply to every story, but they build on the quality foundation created by DoD.

Understanding these levels prevents confusion. A story can meet the team DoD but still require broader release activities before production deployment. However, if stories do not meet DoD, release readiness becomes much harder because unfinished work accumulates and must be cleaned up later.

How Testers Verify Definition of Done

Manual testers verify Definition of Done by checking whether testing-related completion criteria are satisfied. This begins with Acceptance Criteria validation. Each criterion should be tested, and the result should be clear. If a criterion fails, the story is not done, even if most of the feature works.

Testers also verify functional completeness. This means checking that the feature works through realistic user flows, not only isolated field-level behavior. If a password reset story sends the email but does not allow successful login with the new password, the core workflow is incomplete. DoD requires validation of the complete expected behavior.

Regression impact is another important tester responsibility. A change may satisfy its own story but break existing functionality. Testers evaluate affected areas and run relevant regression checks. The size of regression testing depends on risk, but some level of impact assessment should be part of completion.

Defect status must also be reviewed. If a critical or high-severity defect remains open, the story normally should not be considered done. If a lower-severity defect remains, the team and Product Owner must consciously decide whether it is acceptable. The key point is that open issues should be visible, not hidden behind a done status.

Testers may also verify that test documentation is updated. If test cases, regression suites, or acceptance test notes are outdated, future testing becomes harder. A story that changes behavior should leave the testing assets in a usable state. This is an important part of long-term maintainability.

DoD and Preventing Technical Debt

Technical debt is created when teams accept incomplete or low-quality work that must be fixed later. Definition of Done helps prevent technical debt by requiring essential quality activities before work is closed. It does not eliminate all debt, but it reduces hidden unfinished work.

One common source of debt is skipping testing under pressure. A team may mark a story done after coding and promise to test later. This creates a backlog of unverified work. When defects are found later, the team must reopen old context, retest related areas, and possibly delay release. DoD prevents this by requiring testing before completion.

Another source of debt is unresolved defects. If known defects are ignored or postponed without clear ownership, the product becomes less stable over time. DoD should define which defect severities block completion and how accepted defects are documented. This prevents defect handling from becoming informal and inconsistent.

Poor documentation and outdated tests also create debt. When behavior changes but test cases are not updated, future testers may validate the wrong expectations. When configuration or user guidance is not updated, support teams and users may struggle after release. A strong DoD includes the maintenance activities needed to keep the product and its supporting materials reliable.

DoD keeps teams honest about the true cost of work. If a story requires coding, testing, documentation, and defect verification, those activities must be considered during planning. This improves estimation and prevents the false speed that comes from counting unfinished work as complete.

Creating a Practical Definition of Done

A practical Definition of Done should be created collaboratively by the team. The team should discuss what quality activities are necessary for every story and which activities apply only to certain types of work. For example, UI stories may require visual review and accessibility checks, while API stories may require contract validation and response checks.

The DoD should be specific. A vague item such as “testing completed” may not be enough. The team should clarify whether this means acceptance criteria tested, functional scenarios executed, regression impact assessed, defects verified, and test evidence updated. Specific wording prevents different interpretations.

The DoD should also be measurable. The team should be able to answer yes or no for each item. “Code quality is good” is subjective. “Code reviewed and review comments resolved” is measurable. “Feature works properly” is vague. “Acceptance criteria passed and no open critical defects” is clearer.

The DoD should be lightweight enough to use. If the checklist is too long, team members may ignore it or treat it as a formality. The best DoD focuses on meaningful quality gates that protect the product. It should be strong but not overloaded with unnecessary bureaucracy.

Teams should review the DoD periodically, especially after retrospectives, production defects, release issues, or process changes. If recurring problems show that the DoD is missing an important quality check, it should be improved. If some items no longer add value, they can be refined or removed.

Examples of Strong and Weak DoD Criteria

A weak DoD criterion says, “development completed.” This does not define quality. A stronger criterion says, “code completed, reviewed, merged, and verified in the test environment.” This gives the team a clearer standard and avoids treating coding alone as completion.

A weak testing criterion says, “QA done.” This is too broad. A stronger version says, “all acceptance criteria validated, planned functional scenarios executed, regression impact assessed, and no open critical or high defects remain.” This makes testing expectations visible.

A weak documentation criterion says, “documents updated if needed.” This may be acceptable if the team understands what “if needed” means, but it can also be ignored. A stronger criterion identifies which documents may need updates, such as user guide, release notes, API documentation, or test cases.

A weak acceptance criterion says, “Product Owner informed.” A stronger DoD item says, “Product Owner reviewed and accepted the completed story, or open questions are documented and tracked.” This ensures business acceptance is clear.

Strong DoD criteria reduce argument at the end of a sprint. The team does not need to debate whether something is done based on opinion. The criteria provide an agreed reference point for completion decisions.

Definition of Done in Sprint Review

Sprint Review should demonstrate work that meets the Definition of Done. If a story is incomplete, it may be discussed for transparency, but it should not be presented as finished. This matters because stakeholders rely on the team’s definition of completion when evaluating progress.

When the team demonstrates done work, stakeholders can focus on product feedback rather than discovering basic quality issues. The Sprint Review becomes more valuable because the increment is already validated. The discussion can focus on whether the product meets business needs and what should be adapted next.

If incomplete work is repeatedly shown as done, stakeholder trust decreases. Business users may start questioning whether reported progress is real. DoD protects that trust by ensuring that completed work has passed the agreed quality standard before it is demonstrated as complete.

For testers, Sprint Review is also a moment to support quality transparency. If a story meets DoD but has known low-severity limitations, those should be communicated appropriately. If a story does not meet DoD, testers should not support calling it done. This is not negativity; it is professional quality responsibility.

The Sprint Review and DoD work together. DoD defines what completed means. Sprint Review inspects completed product behavior and gathers stakeholder feedback. Together, they support transparent and reliable Agile delivery.

Definition of Done and Continuous Improvement

Definition of Done should improve as the team learns. If production defects repeatedly occur because regression testing is too weak, the team may update DoD to include better regression impact review. If accessibility issues are discovered late, accessibility checks may become part of DoD for UI stories. If release notes are often missed, documentation updates may be clarified.

Sprint Retrospectives are a natural place to inspect DoD. The team can ask whether any sprint problems were caused by incomplete done criteria. If the answer is yes, the DoD may need improvement. This turns real delivery experience into stronger quality standards.

Continuous improvement does not mean changing DoD every sprint without discipline. Frequent uncontrolled changes create confusion. Instead, changes should be deliberate, discussed, and understood by the team. The DoD should remain stable enough to guide work but flexible enough to improve when evidence shows a gap.

As teams mature, DoD often becomes more meaningful. Early teams may focus on basic validation and defect closure. Mature teams may include automation maintenance, performance checks for critical flows, security review for sensitive changes, and accessibility verification. The standard grows with the team’s ability to deliver quality consistently.

The best teams do not treat DoD as a document created once and forgotten. They treat it as a living quality agreement that reflects how the team wants to build and deliver reliable software.

Interview Perspective

Definition of Done is a common Agile interview topic.

Interviewers expect testers to understand how DoD ensures quality.

A short answer defines Definition of Done as criteria that determine completion.

A detailed answer explains how DoD ensures consistent quality standards.

Interviewers often ask about tester responsibilities in Definition of Done.

Strong answers emphasize validation, defect verification, and quality assurance.

Understanding Definition of Done demonstrates real Agile experience.

Key Takeaway

Definition of Done ensures that completion is clearly defined, measurable, and verified.

It ensures that user stories meet agreed quality standards before being marked as complete.

For manual testers, Definition of Done ensures that testing is an essential part of completion rather than an optional step.

A strong Definition of Done ensures that quality is built into the development process, validated through testing, and accepted by stakeholders before work is considered finished.