Definition of Done: What it Means, How to Use it and Practical Examples

Have you ever finished a task, only to be asked, “Can you also add this?” The extra request may be valid, but if no one had agreed on what complete meant, it can be difficult to tell whether the original work was unfinished or whether the request is new scope.

A Definition of Done gives everyone the same practical test for deciding whether work is complete and ready to release, hand over or use.

This factsheet explains what it covers, how it differs from acceptance criteria, how to create one, and how it connects team delivery with quality and governance across the organization.

Watch our short 3-minute video for a quick introduction to the Definition of Done and how it helps prevent the “90% done” trap, then read on to learn how to create and apply one.

In brief

• A Definition of Done is a shared standard for deciding whether work is complete and usable.
• Acceptance criteria describe the need for one item; the Definition of Done covers the recurring quality checks that apply across items or increments.
• Every agreed criterion must be met. Release, handover or use can happen later if the work is scheduled for a later date.
• Keep the standard visible, check it throughout delivery and improve it when evidence shows that a criterion is missing or ineffective.

What is a Definition of Done in Agile?

A Definition of Done, often shortened to DoD, is a shared and transparent agreement describing the minimum activities and quality criteria that a completed piece of work must satisfy. In AgilePM, it is applied to an increment: a usable part of a product or wider solution produced during delivery.

People using Scrum or another agile approach may use different terms or events, but the practical question remains the same: what evidence shows that this work is complete and usable? The criteria should reflect the product, service, risks and organizational standards.

The Definition of Done turns the word done into an evidence-based decision. Work that meets the standard can count as complete, usable and potentially ready for release. Potentially ready does not mean it must be released immediately. It means no further rework should be needed before it can be released, handed over or used in the agreed context.

If one criterion has not been met, the work remains undone. It stays visible and is managed as future work rather than being presented as complete. This does not mean the product can never be improved. Lower-priority enhancements may remain on the future work list, provided they are not part of the agreed scope or quality standard for the current increment.

Why it matters

Without a shared standard, one person may use done to mean drafted, another may mean tested, and a third may mean approved and ready for customers. A Definition of Done removes that ambiguity and gives teams, managers and stakeholders the same view of progress.

• It protects the agreed quality level when deadlines or budgets create pressure.
• It brings review, testing, documentation, compliance and operational readiness into the work instead of leaving them until the end.
• It makes incomplete work visible and supports more realistic planning and forecasting.
• It allows several teams to use the same minimum standard when they contribute to one product or solution.

Understanding the difference between Definition of Done, Acceptance Criteria, and Definition of Ready

Meeting the acceptance criteria is normally one part of meeting the Definition of Done. It is rarely the whole standard. A feature may behave as requested but still be unsafe, inaccessible, poorly integrated or unsupported.

What should a Definition of Done include?

The right criteria depend on the product, service, risks and organizational standards. Use the following areas as a prompt, then keep only what is relevant and testable.

• Expected result: The item meets its agreed acceptance criteria and works as intended.
• Review and testing: The required independent checks are complete, and issues have been handled to the agreed standard.
• Quality characteristics: Relevant standards for accessibility, usability, security, performance, reliability, content or branding are met.
• Integration: The work functions with the other parts of the product or solution.
• Release and handover: No missing activity prevents release or use, and the route to deployment or handover is understood.
• Documentation and support: Necessary guidance, training, operational information and support arrangements are ready.
• Governance: Required legal, regulatory, data protection, information security or other approvals are complete.
• Business acceptance: The person accountable for stakeholder value has confirmed that the result is fit for purpose.

Example of a Definition of Done

A new employee expenses service

Imagine that a team is delivering the first usable version of an expenses service for employees, managers and the finance team.

The acceptance criteria for this particular increment are:

• An employee can enter the required claim details, attach a receipt and submit the claim.
• The service explains what is missing and prevents submission when required information is incomplete.
• A manager can approve or reject a claim and record a reason.
• The employee can see the decision, and an approved claim reaches finance with an audit record.

The team also applies its Definition of Done. All acceptance criteria must pass; another team member must review the work; accessibility, security and data protection checks must be complete; the finance integration must be tested; support guidance must be ready; and the person accountable for the service and any required legal, security or compliance reviewers must approve the result.

At the review, the form works and managers can approve claims, but the accessibility check is incomplete and the finance support guide is missing. The increment does not yet meet the Definition of Done. The missing work remains visible and must be completed before the team can claim completion. Once every criterion is met, the increment can count as Done even if the organization schedules the launch for a later date. A proposed reporting dashboard may remain on the future work list if it was not part of the agreed increment.

A policy change

The same approach works beyond digital services. A team is introducing a new hybrid-working policy. The acceptance criteria for the policy state that employees can find the eligibility rules, understand how to make a request, and see the response times and responsibilities for employees and managers.

The Definition of Done adds the checks that make the policy ready for use:

• HR and legal review are complete, including any required equality, employment or data protection checks.
• The policy has been checked for accessibility, plain language and consistency with related guidance.
• The approved policy is published in the agreed location, with an effective date and version record.
• Managers have the briefing or guidance they need, and employees know where to ask questions.

If the policy has been approved but is not published and managers have not been briefed, it is not Done. The approval is evidence that one criterion has been met; it does not replace the remaining checks.

How to create and use a Definition of Done

1. Decide what the standard covers.
   State whether it applies to each product increment, to an integrated solution, or to both. A solution-level Definition of Done needs to cover how separate products, processes and services work together.
2. Start with mandatory standards.
   Identify organizational, legal, regulatory and professional requirements. If the organization already has a minimum Definition of Done, teams must incorporate it rather than replace it with a weaker local version.
3. Bring together the right perspectives.
   Include people who understand stakeholder needs, people who build and test the work, and people responsible for architecture, operations or compliance. In AgilePM, the Solution Architect is responsible for the solution quality standards. Delivery Teams apply those standards, and business representatives confirm that the result is fit for purpose.
4. Separate specific needs from the common standard.
   Put conditions unique to one item in its acceptance criteria. Put checks that every increment must pass in the Definition of Done. Use a separate solution-level Definition of Done when integration and organizational readiness need a wider check.
5. Write observable criteria.
   Replace wording such as high quality or fully tested with conditions that people can verify. State the evidence required and who is authorized to accept it. Approval is one criterion; it cannot make untested work complete.
6. Plan the work needed to meet it.
   The Definition of Done affects the effort a team can complete, so review it during planning. Review, testing, documentation and readiness activities belong inside delivery, not in a separate clean-up phase after the deadline.
7. Inspect and improve it.
   Use regular team reviews, often called retrospectives in agile work, to identify missing or ineffective criteria. The Definition of Done can mature as the product and delivery approach evolve, but do not lower it at the end of a delivery period simply to make unfinished work appear complete.

Keep the current Definition of Done where people manage the work. During planning, confirm that the work includes time for every criterion. During review or handover, link each criterion to evidence. If an exception is accepted, record the decision and its owner rather than silently marking the work as Done.

Using a Definition of Done across several teams

Teams working on the same product should use one mutually agreed Definition of Done. Separate local standards make integration and progress harder to understand. Where several products or services combine into a wider solution, a solution-level Definition of Done adds checks for integration, architecture, operational readiness, support and approvals that apply across the solution. A component can therefore be Done at product level while the assembled solution is not yet Done.

How it connects to business agility

Our Framework for Business Agility encourages organizations to consider the whole system rather than treating agile delivery as an isolated team activity. A Definition of Done creates a practical connection between team delivery and the wider organization. Customer and user expectations shape acceptance, while governance contributes mandatory standards. Delivery teams build and test the solution; operations and support define what is needed for safe use; and leaders make the quality standard clear and achievable.

Common problems to avoid

The essential takeaway

A Definition of Done makes completion a shared decision supported by evidence. It defines the minimum quality required for the current increment to be usable and complete. The product or service may continue to improve afterwards. Agree the standard early, apply it throughout delivery, keep unfinished work visible and improve the criteria as the solution evolves.

Continue developing your practice

Use our free Framework for Business Agility to examine how customer value, governance, leadership, change, operations and support work together across your organization.

If you’re looking for structured learning or a professional certification, explore AgilePM for agile project delivery or AgileBA for business analysis in agile environments.

To develop and apply agile ways of working in your own context, explore Individual Membership for self-paced courses, practical resources, member events and practitioner communities.