Definition of Done

Q: When the Definition of Done Does Not Apply

A Definition of Done functions best when a team produces repeated, potentially shippable increments that share a common quality standard. It does not resolve every completion question in project work. It does not apply well to isolated, non-product activities such as early discovery research, procurement tasks, or administrative work that does not contribute directly to an increment. In those cases, the team may still need explicit completion criteria, but calling those criteria a Definition of Done can force a quality standard onto work that is not meant to be released. The model also breaks down when no team has the authority or ability to verify the criteria. If an organization lacks test environments, access to real users, or authority to deploy, a Definition of Done can become aspirational rather than operational. A team may list security review as a done criterion, but if security reviews are controlled by a separate department with unpredictable availability, the team cannot honestly call its increment done. Similarly, in heavily regulated environments, a Definition of Done cannot replace formal compliance approval. The team's internal standard may be met while a legal or regulatory sign-off is still pending. In these boundary situations, the Definition of Done describes team-level completion, not organizational release authorization. Treating it as a substitute for external approval would be a category error. The concept is most useful when the team controls the work needed to meet its own quality standard and can make that standard transparent to stakeholders.

Business Value-Oriented Principles Ltd.

Definition of Done

Published on: August 21, 2026 Edited on: August 21, 2026

Author: BVOP

The Definition of Done is a formal, mutually agreed set of criteria that a deliverable or product increment must meet to be considered complete. It establishes a shared standard of quality by requiring that work is tested, documented, integrated, and ready for release. In Agile and Scrum, the Definition of Done separates in-progress work from work that is ready to ship and is assessed during sprint reviews.

Establishing Agreed Standards for Work Completion

The Definition of Done is a formal and mutually agreed set of criteria that a deliverable, product increment, or work item must satisfy before it is considered complete. It defines the boundary between work that is still in progress and work that is genuinely deliverable, tested, documented, and ready for use. In project management, the term is most commonly associated with Agile and Scrum, but the underlying idea appears in any environment where teams need a shared standard for completion. Without it, "done" becomes a subjective and often contested claim.

Agile Definition of Done criteria ensuring transparent, team-specific work completion standards.

Definition of Done: Key Topics Summary

Key Concept	Summary
Core Definition	A formal, jointly agreed set of criteria that a deliverable, product increment, or work item must meet before any stakeholder can treat it as complete.
Agile and Scrum Context	Most closely associated with Agile and Scrum, the concept applies to any team that benefits from a shared, explicit completion standard.
Software Team Standard	Many software teams define work as complete only after code passes peer review, automated tests pass, user documentation is updated, and the change is merged into a release branch.
Story-Level Criteria	Teams may require a feature to function in a staging environment, include edge case tests, and receive product owner verification before the story is accepted.
Beyond Task Completion	The standard extends beyond a simple task completion note because it includes verification, integration, and documentation activities that often occur after initial development or drafting.
Operational Analogy	In a professional kitchen, a plate is not considered ready when it is plated; it is ready only after the sauce is checked, the garnish is correct, and the pass has visually inspected the order.
Industry-Specific Criteria	Hardware teams may add manufacturing readiness and safety certification; content teams may require editorial review, legal clearance, and final publication formatting.
Program-Level Criteria	At the program level, completion criteria may extend to cross-system regression testing, security scanning, customer documentation updates, and validation of data privacy, load tolerance, and accessibility, many of which remain invisible in a product demo.

What Is the Definition of Done?

The Definition of Done definition centers on explicit completion criteria rather than implied understanding. It is not a description of what the product should do. That is the role of acceptance criteria. Instead, the Definition of Done describes the quality standards and work activities that must be true for any product increment the team delivers. A team may decide that no work item is done until code is peer reviewed, automated tests pass, user documentation is updated, and the change is merged into a release branch. This shared checklist reduces the chance that hidden work remains after a status update says complete.

Core Meaning in Agile and Project Delivery

In Agile delivery, the Definition of Done represents a consensus among the team about what constitutes shippable quality. It functions as an internal standard rather than an external customer approval mechanism. A team might decide that a user story is not done unless the feature works in a staging environment, edge cases are tested, and the product owner has verified the result. This differs from a simple task completion note, because the Definition of Done includes activities that often happen after initial coding or drafting is finished. It captures integration, testing, documentation, and compliance work that is easy to overlook when progress is measured by tasks checked off a list.

When someone new to project delivery asks why a story that works on a developer's machine is still not done, the Definition of Done answer is that the team has broader criteria. A plate might look finished when the chef plates it, but the kitchen does not call it ready until the sauce is checked, the garnish is correct, and the pass has visually inspected the order. In the same way, a software feature may be coded but still require review, testing, and release preparation before it meets the team's standard. That practical reality is what the formal checklist captures.

How the Definition of Done Differs Across Teams

The Definition of Done is context specific. A hardware engineering team may include manufacturing readiness and safety certification in its Definition of Done, while a content production team may include editorial review, legal clearance, and publication formatting. In software teams, the criteria often include code coverage, user acceptance testing, accessibility checks, performance testing, and deployment to a controlled environment. Because teams have different products, risk profiles, and organizational requirements, there is no universal Definition of Done. Even within the same organization, two teams working on different subsystems may legitimately operate with different definitions, although leadership often benefits from alignment at the release or program level.

This diversity sometimes creates friction in scaled environments. A product increment that passes one team's Definition of Done may not satisfy another team's integration requirements. That is why programs and large projects often introduce a shared or layered Definition of Done at the release train, solution, or program level. The team-level definition remains the baseline, but additional program-level criteria may include cross-system regression testing, security scanning, and customer documentation updates. The combined standard ensures that a collection of team-level increments can form a releasable product.

Core Insights on the Definition of Done

Shared quality checklist: The Definition of Done serves as a shared quality checklist that codifies the team's agreed standards and verification activities that every product increment must satisfy before it can be accepted as complete.
Beyond simple task completion: It extends beyond the initial coding or drafting effort to include integration, testing, documentation, and verification, ensuring that no hidden work remains after a task is reported complete.
Tailored to each team's context: Software, hardware, and content teams tailor these criteria to their own delivery context, with software teams applying code coverage and automated deployment checks, hardware teams requiring manufacturing readiness, and content teams enforcing editorial review before publication.

Key Components of the Definition of Done

The key components of the Definition of Done typically fall into three categories: product-related quality criteria, nonfunctional assurance, and process compliance. Product-related criteria verify that the increment works as intended and integrates with the rest of the system. Nonfunctional assurance includes performance, security, accessibility, and operational readiness. Process compliance covers documentation, approvals, and audit trails. A well-formed Definition of Done makes these components explicit enough that a new team member can review the list and determine whether an increment is actually complete.

Functional Quality Criteria

Functional quality criteria answer whether the work item meets its intended behavior. This may include automated unit tests, integration tests, feature tests, and exploratory testing sessions. Many teams include a requirement that no known critical or high-severity defects remain open. Some include peer review of code or design work. The criteria may also require that the increment has been demonstrated to the product owner or business representative. These components focus on product correctness rather than internal team preference.

Nonfunctional and Organizational Criteria

Nonfunctional components are often the source of hidden rework. Security scanning, data privacy validation, load testing, and accessibility verification may not be visible in a demo, but they determine whether the product can safely go live. Documentation updates, release notes, and configuration management records also sit in this category. In regulated industries, the Definition of Done may include evidence required for audits, such as traceability from requirement to test result. This ensures that a feature is not just functionally complete but also organizationally acceptable.

Process and Documentation Criteria

Process criteria create repeatability. A team may require that the work item has been merged into the main branch, that the continuous integration pipeline is green, and that any operational runbooks are updated. The purpose is not to create paperwork for its own sake. The purpose is to ensure that completion is visible, verifiable, and reversible if needed. Some teams include a criterion that the increment has passed a release readiness review or that the sprint review has been completed. These process elements make the Definition of Done a control mechanism as much as a quality standard.

Definition of Done in Project Management Frameworks

The Definition of Done in project management is not a standalone PMBOK process, but it connects directly to quality management, scope validation, and integrated change control. Predictive environments often use analogous tools such as completion checklists, quality criteria, and phase exit criteria. The underlying management principle is the same: a deliverable is not complete until it meets a pre-agreed standard of quality, documentation, and acceptance. The Definition of Done brings this principle into iterative delivery with a lightweight and team-owned format.

Definition of Done in Agile and Scrum

In Scrum, the Definition of Done is a formal description of the state of an Increment when it meets the quality measures required for the product. The Scrum Team owns and maintains it. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. This language is deliberately firm because the Definition of Done supports transparency. Without it, stakeholders cannot reliably understand whether an increment is potentially releasable.

Agile scaling frameworks extend the concept. Large-scale Scrum and the Scaled Agile Framework encourage team-level definitions aligned to release-level or solution-level definitions. In SAFe, teams may have a local Definition of Done, but the Agile Release Train often defines additional release criteria. This layered approach keeps the team-level practice fast while ensuring that the whole system is release ready.

Definition of Done in PMBOK and Predictive Delivery

The PMBOK Guide does not use the term Definition of Done as a named process, but the concept maps to several areas. In predictive projects, the equivalent thinking appears in the Plan Quality Management process, quality control measurements, and verified deliverables. A deliverable in the Validate Scope process must be checked against the project management plan and customer requirements. The Definition of Done plays a similar role at the iteration level, while scope validation plays it at the project or phase level. Some project managers in hybrid environments use the Definition of Done to make quality control faster inside a phase gate structure. The checklist is not a replacement for formal acceptance, but it reduces the chance that a deliverable reaches formal validation with obvious quality gaps.

Definition of Done in PRINCE2 and Hybrid Environments

PRINCE2 manages quality through product descriptions, quality criteria, quality methods, and the quality register. A product description defines the required quality criteria and acceptance method for a product. The Definition of Done operates in a similar space, though PRINCE2 separates quality checking from project control more explicitly. In a hybrid PRINCE2 and Agile setup, a team may use the Definition of Done to satisfy stage quality expectations before a stage boundary is assessed. The project board still controls stage progression, but the team has a transparent internal standard for what finished means. This combination works when the organization needs strong governance without sacrificing the team's operational autonomy.

Key Insights: DoD Across Frameworks

DoD bridges quality management practices: Although the Definition of Done is not a standalone PMBOK process, it directly supports quality management, scope validation, and integrated change control as a measurable quality gate for completed work.
Scrum's formal Increment quality standard: In Scrum, the Definition of Done formally specifies the quality state that an Increment must achieve before it can be considered complete, and organization-wide standards set the minimum quality baseline that every Scrum Team must apply.
Scaled frameworks align DoD levels: LeSS and SAFe promote team-level Definitions of Done that align with release-level or solution-level definitions to preserve consistency across multiple teams, while hybrid environments leverage the DoD to strengthen quality control within traditional phase gate structures.

Purpose and Importance of the Definition of Done

The purpose and importance of the Definition of Done lie in its ability to make undone work visible. When a team simply marks tasks as complete in a tool, stakeholders may mistake activity for delivery. The Definition of Done forces a different conversation. It asks whether the increment has met a known quality threshold. This reduces the optimistic reporting that often plagues project status meetings, where progress is overstated because coding, writing, or building appears finished but the supporting work is not.

Reducing Ambiguity in Delivery

Ambiguity around completion creates conflict. A developer may say a feature is done after the code is written. A tester may say it is not done until the test plan passes. A product owner may say it is not done until the user journey is verified. Without a shared Definition of Done, these perspectives collide late in the project. The Definition of Done aligns these expectations early. It gives the team a common language for status, quality, and risk. This is particularly valuable when distributed teams or external contractors are involved, because assumptions about completion vary widely across organizations.

Enabling Reliable Forecasting

Reliable forecasting depends on knowing how much work can actually be completed in a period. If the Definition of Done is weak, stories may appear complete in a sprint but require significant rework later. That hidden rework inflates velocity and distorts cycle time. A strong Definition of Done makes velocity more meaningful because the team counts only work that has genuinely met its quality standard. It also improves release planning. The product owner can trust that items marked done do not carry a large backlog of cleanup tasks into the next iteration.

Definition of Done vs Acceptance Criteria

The Definition of Done vs Acceptance Criteria distinction is one of the most frequently misunderstood areas in Agile delivery. Acceptance criteria describe what a specific product backlog item must do to satisfy the user or customer. The Definition of Done describes how any product backlog item must be delivered to meet the team's quality standard. A grocery shopping analogy clarifies the difference. Buying three ripe avocados is an acceptance criterion for a specific shopping item. Ensuring all groceries are bagged, paid for, and within their expiration dates is a Definition of Done that applies to the whole trip. Acceptance criteria vary by item. The Definition of Done is stable across items in the same context.

This distinction matters because both are needed. Acceptance criteria alone tell you the feature is functionally correct, but they do not guarantee the code was reviewed, tested for security, documented, and deployed appropriately. The Definition of Done covers those shared requirements. Conversely, the Definition of Done does not tell you whether the feature actually solves the customer's problem. A team can meet its Definition of Done and still deliver the wrong feature. That is why the two concepts are complementary rather than substitutes.

Key Takeaways on Done vs Acceptance

Acceptance criteria target specific items: Acceptance criteria define the specific conditions a product backlog item must satisfy to meet user or customer expectations, such as buying three ripe avocados during a grocery run.
Definition of Done applies to all items: The Definition of Done specifies the quality standards every product backlog item must meet before delivery, and it remains consistent across items in the same context, just as all groceries must be bagged, paid for, and within their expiration dates.
Each concept covers different gaps: Acceptance criteria verify functional correctness but do not guarantee code review, security testing, documentation, or proper deployment, whereas the Definition of Done does not indicate whether a feature truly solves the customer's problem.
Satisfying Definition of Done is not enough: A team can meet its Definition of Done and still deliver the wrong feature, because the Definition of Done only verifies delivery quality, not whether the feature addresses the customer's actual need.

Common Misconceptions and Pitfalls

One of the common misconceptions about the Definition of Done is that it is a bureaucratic checklist imposed by management. In healthy Agile practice, the team creates and evolves the Definition of Done based on real quality needs and organizational constraints. It is not a performance scorecard. Another misconception is that the Definition of Done must be identical for every team in a company. While some organizational standards are useful, forcing identical definitions onto unrelated products can add irrelevant work and slow delivery. The checklist should be fit for purpose.

Treating the Definition of Done as Static

Teams sometimes write a Definition of Done once and never revisit it. That is a mistake. As the product matures, the technical environment changes, and customer risk tolerance shifts. The Definition of Done should evolve to include new security requirements, deployment practices, or monitoring needs. A static definition can become either too weak to protect quality or too heavy to support frequent delivery. Regular retrospective reviews of the Definition of Done help the team align its standard with current reality.

Using It as a Weapon or Bureaucratic Barrier

A Definition of Done can be misused when individuals reject work for reasons that are not in the agreed definition. This creates conflict and erodes trust. It can also become a bureaucratic barrier when management adds criteria without removing obsolete ones. Overloading the Definition of Done with every possible quality activity turns each increment into an expensive bottleneck. The team should be able to explain why each criterion exists and what risk it reduces. If a criterion only exists because someone once asked for it, the team should question its continued value. The point is not to maximize the number of checks. The point is to maintain a reliable and practical completion standard.

Practical Application of the Definition of Done

The practical application of the Definition of Done spans planning, execution, monitoring, and closure. At the planning stage, the team reviews and revises the definition before committing to new work. During execution, the definition guides developers, testers, designers, and content producers as they move items toward completion. During sprint review or phase review, the definition supports the team's claim that work is complete. At release and closure, the definition provides evidence that the product or increment has met the established quality threshold. This continuous presence is what makes it a management control rather than a one-time form.

At Planning and Sprint Kickoff

Before a sprint begins, the team should confirm that its Definition of Done still reflects the product and technical context. If the organization has introduced a new security scanning requirement or a new documentation standard, that change belongs in the definition before work begins. This prevents mid-sprint surprises. The Definition of Done also helps the team estimate capacity. If the definition is strong, fewer hidden tasks will remain after coding or drafting is complete.

During Execution and Quality Control

During execution, team members use the Definition of Done as a daily reference. A developer may run unit tests, ask for peer review, and update deployment scripts because the definition requires those steps. A tester may focus first on the conditions that block a story from being done. This self-directed behavior reduces the need for a project manager to chase each task. The team controls quality at the point of work. In predictive environments, project managers often use a similar checklist during quality control before approving deliverables for Validate Scope.

At Release and Closure

At release time, the aggregate Definition of Done across all included items provides confidence in the product. If every story met the team's definition, the release is less likely to contain hidden defects, missing documentation, or broken integrations. Some organizations combine the Definition of Done with release management checklists that include operational rollback plans, customer communication, and monitoring alerts. The Definition of Done is not a replacement for release management, but it supplies the quality foundation. At project closure, the historical record of definitions can also inform lessons learned for future projects.

Key Insights on DoD in Practice

Four-stage lifecycle application: Teams apply the Definition of Done at every stage of the project lifecycle, using it to anchor planning, execution, monitoring, and closure activities.
Planning stage revisions: Before committing to new work, teams refresh the Definition of Done to reflect the current product and technical context, incorporating emerging security, compliance, and documentation requirements.
Execution role guidance: The Definition of Done translates completion criteria into role-specific actions, prompting developers, testers, designers, and content producers to run unit tests, request peer reviews, and update deployment scripts before work is declared complete.
Review and release evidence: During sprint and phase reviews, the Definition of Done anchors completion claims, and at release it supplies auditable evidence that the increment has met the agreed quality threshold.
Release checklist integration: Many organizations embed the Definition of Done within release management checklists that also specify operational rollback plans, customer communication protocols, and monitoring alerts.

BVOP Perspective on the Definition of Done

The BVOP perspective on the Definition of Done aligns completion with business value rather than activity alone. Business Value-Oriented Project Management treats employee-created tools, open-source software, and enabling work as formal products when they contribute to delivery capability. This means a Definition of Done in a BVOP environment may include not only customer-facing feature quality but also the reusability of internal tools or the documented health of a cross-functional team's delivery assets.

Evolution and Current Thinking

The evolution of the Definition of Done reflects a broader shift from process compliance to value assurance. Early Agile teams often adopted a simple checklist such as code complete, unit tested, and deployed to staging. As software delivery became more complex, definitions expanded to include security, performance, accessibility, data privacy, and observability. The concept has also spread beyond software into marketing operations, product design, content production, and infrastructure projects. In those contexts, the label may vary, but the management principle remains stable: define completion before starting work.

From Simple Checklist to Team Commitment

The original purpose of the Definition of Done was to improve transparency in Scrum. Over time, experienced practitioners began treating it as a social contract within the team. It is not only a list of tasks. It is a commitment to not declare work complete when known quality gaps remain. This shift has practical consequences. Teams that view the Definition of Done as a commitment are more likely to challenge unrealistic deadlines rather than silently reduce quality. Organizations that view it only as a checklist may still experience gaming, where items are marked done despite unmet criteria because the team feels schedule pressure.

Current Debates and Context-Dependent Practice

There is ongoing debate about how strict a Definition of Done should be. Some practitioners argue that every increment must be potentially releasable, which implies a very strong definition. Others note that in early product discovery, a heavy Definition of Done can slow learning. In those contexts, the team may use a provisional definition that focuses on learning outcomes rather than production readiness. This is not a violation of Agility. It is a conscious decision to match the quality standard to the stage of the product and the risk involved. The key is that the team makes the choice explicitly rather than allowing the definition to drift.

Key Insights on Done Evolution

From compliance to value assurance: The Definition of Done now serves as a value assurance mechanism, confirming that work declared complete actually satisfies customer needs and quality standards instead of merely passing procedural checks.
Expanded scope beyond basic checks: Modern definitions extend well beyond functional validation to include security, performance, accessibility, data privacy, and observability requirements, reflecting the higher expectations placed on contemporary software systems.
Adoption across non-software domains: The principle has spread into marketing operations, product design, content production, and infrastructure projects, where teams may use different labels but still define completion criteria before work begins.
Social contract within teams: Experienced practitioners view the Definition of Done as a social contract that prevents teams from declaring work finished while known quality gaps remain, making it a safeguard for professional accountability rather than a simple transparency tool.
Checklist mindset enables gaming: When organizations treat the Definition of Done as a mere checklist, schedule pressure often leads teams to mark incomplete items as done, whereas teams that embrace it as a shared commitment are more likely to challenge unrealistic deadlines.

Relationship to Other Project Management Concepts

The relationship between the Definition of Done and other project concepts is often navigated through three adjacent ideas: the Definition of Ready, quality gates, and work in progress limits. Each plays a different role in delivery. The Definition of Ready clarifies whether work is sufficiently understood before it enters a sprint. Quality gates are control points at which a deliverable is reviewed against defined criteria. Work in progress limits constrain how much work can be active at once. The Definition of Done completes this set by defining what it means to finish the work.

Definition of Ready

The Definition of Ready is the upstream counterpart to the Definition of Done. It specifies the information, clarity, and acceptance criteria a backlog item must have before the team accepts it into a sprint. The Definition of Done specifies the delivery standard for the same item as it exits the sprint. Together, they create a clear boundary around the team's work process. A team can have a strong Definition of Done but still struggle if its Definition of Ready is weak, because poorly understood work often moves through the sprint with unresolved assumptions that surface during testing.

Quality Gates and Exit Criteria

In predictive project management, quality gates and phase exit criteria serve a similar function to the Definition of Done. A quality gate is a review point where a deliverable must meet predefined standards before the project can proceed to the next phase. The Definition of Done is more granular and iterative, applying to individual work items or increments. Many hybrid projects use both. The Definition of Done operates continuously within a phase, while quality gates operate at phase boundaries. This combination supports both speed and governance.

Work in Progress Limits and Cumulative Flow

Work in progress limits and cumulative flow diagrams relate to the Definition of Done through flow efficiency. If work items meet the Definition of Done too easily, the team may not be surfacing hidden rework. If the definition is too heavy, work items linger in progress and flow efficiency drops. Cumulative flow diagrams can reveal a growing done column that is not actually releasable because the Definition of Done is weak or inconsistently applied. In this way, the Definition of Done affects not only quality but also the team's ability to understand and improve its own delivery system.

Limitations of the Definition of Done

The limitations of the Definition of Done become visible when the concept is applied mechanically outside its useful context. It is not a substitute for customer acceptance, contractual sign-off, or regulatory approval. A team can satisfy its Definition of Done and still have a product that fails in real market conditions. It also does not resolve deeper scope problems. If the product backlog contains the wrong features, a strong Definition of Done will simply help the team deliver the wrong features faster. Recognizing these limitations prevents the team from treating the checklist as an all-purpose quality guarantee.

The Definition of Done can also be poorly suited to creative or exploratory work with no stable completion standard. In early research, design discovery, or innovation projects, the criteria for done may need to change frequently. Applying a rigid Definition of Done in these settings can produce false precision. Teams in such environments often use learning objectives, decision outcomes, or experiment results instead. A standard created for repeatable delivery work does not transfer automatically to high-uncertainty discovery work.

Key Limitations of Definition of Done

Not a Substitute for Approvals: The Definition of Done is not a substitute for customer acceptance, contractual sign-off, or regulatory approval, and meeting its criteria does not guarantee that the product will succeed in actual market conditions.
Speeds Up Wrong Feature Delivery: When the product backlog contains the wrong features, a strong Definition of Done simply enables the team to deliver those incorrect features faster rather than improving product-market fit.
Poor Fit for Exploratory Work: For research, design discovery, and innovation initiatives, completion criteria shift continuously, so a rigid Definition of Done imposes false precision and is better replaced by learning objectives, decision outcomes, or experiment results.

Definition of Done Explained as a Completion Standard

The Definition of Done explained in its simplest form is a shared quality contract for finishing work. It makes completion observable, consistent, and discussable. The concept endures because it addresses a universal problem in project delivery: the gap between activity and value. When a team can point to a written list and say that every item on it has been met, status conversations become faster and more factual. When the list is ignored, project reports drift into optimistic fiction.

That simplicity should not hide the skill required to maintain a good Definition of Done. It must be specific enough to prevent surprise rework, but flexible enough to change with the product and the organization. It must reflect local reality without becoming a bureaucratic burden. It must be owned by the people who do the work, even when governance requires organizational alignment. Those tensions are not flaws in the concept. They are the normal conditions of real project management.

Key Distinctions & Clarifications

Definition of Done vs. Acceptance Criteria

The Definition of Done and acceptance criteria are often confused because both describe conditions that must be met before work can be considered complete. The key difference is scope and object. The Definition of Done applies to every increment or work item the team produces.

It is a uniform quality standard that the team commits to across all backlog items. Acceptance criteria, in contrast, are unique to a single product backlog item or user story. They describe the functional behavior, business rules, or specific outcomes that a particular feature must exhibit to satisfy the product owner or customer.

For example, a user story for password reset might have acceptance criteria such as: the system sends a reset link, the link expires after 30 minutes, and the user cannot reuse the previous password. These criteria confirm that the feature behaves correctly. The Definition of Done, however, would include broader completion requirements that apply to that story and every other story, such as code peer review, automated test coverage, accessibility checks, and documentation updates.

A story can meet all its acceptance criteria and still not be done if the team has not completed the required review and testing activities. Conversely, a story that has passed the Definition of Done may still fail acceptance if the implemented behavior does not match the product owner's expectations. The two work together: acceptance criteria define what to build for a specific item, while the Definition of Done defines how the team knows any item is genuinely releasable.

The Emergence of the Definition of Done in Agile Practice

The Definition of Done does not have a single, documented inventor. It emerged from the early Agile software community as teams sought to distinguish between code that was merely written and code that was truly ready for release. In the late 1990s and early 2000s, Extreme Programming practitioners used the informal phrase "done done" to signal that a feature had passed all coding, testing, and integration steps, not just the initial implementation.

This vocabulary spread through early Agile literature and conferences as a reaction against vague status reports that overstated progress. Scrum later formalized the concept. Ken Schwaber and Jeff Sutherland, the co-creators of Scrum, included the Definition of Done in the Scrum Guide as a commitment that supports the Increment and ensures transparency about what it means for work to be complete.

The Scrum Guide emphasizes that each Scrum Team must agree on its own Definition of Done, because completion standards vary by product, technology, and organizational context. Over time the meaning shifted from an informal team agreement to a more structured governance artifact. Organizations began publishing organization-wide minimum standards for done, which individual teams could extend but not weaken.

This evolution reflects a broader change in Agile thinking: completion is not a feeling or a single role's judgment, but an explicit, inspectable, and continuously maintained standard.

When the Definition of Done Does Not Apply

A Definition of Done functions best when a team follows an adaptive development approach and produces repeated, potentially shippable increments that share a common quality standard. It does not resolve every completion question in project work. It does not apply well to isolated, non-product activities such as early discovery research, procurement tasks, or administrative work that does not contribute directly to an increment.

In those cases, the team may still need explicit completion criteria, but calling those criteria a Definition of Done can force a quality standard onto work that is not meant to be released. The model also breaks down when no team has the authority or ability to verify the criteria. If an organization lacks test environments, access to real users, or authority to deploy, a Definition of Done can become aspirational rather than operational.

A team may list security review as a done criterion, but if security reviews are controlled by a separate department with unpredictable availability, the team cannot honestly call its increment done. Similarly, in heavily regulated environments, a Definition of Done cannot replace formal compliance approval. The team's internal standard may be met while a legal or regulatory sign-off is still pending.

In these boundary situations, the Definition of Done describes team-level completion, not organizational release authorization. Treating it as a substitute for external approval would be a category error. The concept is most useful when the team controls the work needed to meet its own quality standard and can make that standard transparent to stakeholders.

Misunderstandings About the Definition of Done

One common misinterpretation is that the Definition of Done is simply another name for acceptance criteria. Misinterpretation: acceptance criteria and the Definition of Done are interchangeable. Fact: acceptance criteria describe the specific behavior of one work item, while the Definition of Done applies as a uniform quality standard across all increments.

Another frequent error is treating the Definition of Done as a fixed checklist. Misinterpretation: once a team writes its Definition of Done, that standard remains stable. Fact: the Definition of Done is meant to be inspected and adapted as the team learns more about product risks, tooling, and stakeholder needs through ongoing improvement.

A team that never revisits its done criteria may continue to enforce checks that are no longer valuable or may miss new quality requirements. A third misinterpretation is that satisfying the Definition of Done means the increment is approved for public release. Misinterpretation: meeting the Definition of Done authorizes a release.

Fact: the Definition of Done establishes that the work is complete from the team's perspective, but release approval may depend on additional business, legal, marketing, or compliance gates. Some teams combine their Definition of Done with release criteria, but the concepts remain distinct. A fourth misunderstanding is that the Definition of Done must be identical across all teams in an organization.

Misinterpretation: organizational consistency requires one shared Definition of Done. Fact: while shared organizational standards can support alignment, Scrum allows teams to define their own standards if they meet or exceed any organizational minimum.