Definition of Done vs Acceptance Criteria vs Quality Metrics.

Shared completion, specific acceptance and measurement

Definition of Done: one transparent quality state

The Scrum Guide defines the Definition of Done as a formal description of the Increment's state when it meets the quality measures required for the product. Once a Product Backlog item meets it, an Increment is born. Work that does not meet it is not part of the Increment.

• Creates a shared understanding of what completed work means.
• Applies consistently to Increment work, not only one selected feature.
• Includes relevant verification, integration, documentation, security or other product quality expectations.
• Uses organizational standards as a minimum when they exist.
• Must be shared by multiple Scrum Teams working on the same product.

Current Scrum rule: an item that does not meet the Definition of Done cannot be released or presented at the Sprint Review as completed. It returns to the Product Backlog for future consideration.

Acceptance criteria: conditions for one item

Acceptance criteria make a specific need observable and testable. They clarify expected behavior, business rules, boundaries, data conditions and error handling so stakeholders and the team can reach a shared understanding before verification.

Acceptance criteria are widely used but are not defined as a formal Scrum artifact or commitment. They can be expressed through examples, rules, scenarios or tests. Keep them specific enough to verify without turning every item into a complete product-quality policy.

Quality metrics: quantify performance

A quality metric specifies what will be measured, how it will be measured, the unit, frequency and acceptable range. Metrics turn vague statements such as “fast” or “reliable” into evidence that supports decisions.

A metric is useful only when its purpose, data source and decision threshold are clear. Avoid vanity measures that are easy to collect but do not guide prevention, control or improvement.

How all three work together

1. Acceptance criteria define what the individual item must do for its intended user or stakeholder.
2. The team builds and verifies the item against those specific conditions.
3. The Definition of Done adds the shared product-quality requirements needed for the work to count as part of an Increment.
4. Quality metrics measure whether the product and process achieve required performance, reliability or defect outcomes.
5. Review evidence and improve criteria, engineering practices or process when results expose a gap.

An item may demonstrate its requested business behavior yet still be incomplete because security testing, integration, documentation or another Definition of Done requirement is missing. Likewise, checking boxes does not guarantee a good outcome if quality metrics show deteriorating reliability.

Worked scenario: online payment confirmation

A team adds payment confirmation to an e-commerce platform.

1. Item acceptance criteria require the correct order number, amount, masked payment method and confirmation status for approved and declined transactions.
2. The product Definition of Done requires peer review, automated tests, security scanning, audit logging, accessibility checks, updated support notes and successful integration.
3. A quality metric requires the confirmation endpoint's 95th-percentile response time to remain below two seconds at the documented load.
4. The feature passes its functional acceptance examples but fails the security scan.
5. The team does not call it Done or present it as a completed Increment; it addresses the vulnerability and reruns required checks.
6. After release, the response-time metric exposes a load-related regression, prompting root-cause analysis and improvement.

Each tool answers a different question: did the item do the right thing, was the work completed to the shared standard, and how well is the product performing?

Respond to a quality failure

1. Contain impact: protect users, data and regulatory obligations before optimizing schedule.
2. Confirm the failed condition: item acceptance, Definition of Done, external standard or measured quality threshold.
3. Analyze root cause: avoid blaming an individual or fixing only the visible symptom.
4. Correct the work: update the item and retest affected integration and regression paths.
5. Improve prevention: strengthen the Definition of Done, acceptance examples, automation, review or process where evidence supports it.
6. Make the problem visible: update quality reports, risks, defects and stakeholder communication through the selected delivery approach.

On PMP questions, prevention and collaborative root-cause improvement are usually stronger than accepting known defects to protect a date or adding inspection only at the end.

PMP practice checks with explanations

Common PMP exam mistakes

• Using item acceptance criteria as the entire Definition of Done.
• Calling partially tested work Done because the Product Owner likes the demonstration.
• Treating the Sprint Review as a quality gate or the only release point.
• Confusing a quality metric with a vague aspiration.
• Tracking measurements without a target, tolerance or decision purpose.
• Inspecting quality only at the end instead of building it into delivery.
• Adding every one-off requirement to the product-wide Definition of Done.
• Ignoring organizational or regulatory minimum standards.

Frequently asked questions

Official references

Use the official current Scrum Guide for the Increment and Definition of Done. PMI provides supporting guidance through the July 2026 PMP Examination Content Outline, the Agile Practice Guide, quality requirements guidance and the Disciplined Agile glossary. Tailor criteria and metrics to product, regulatory and organizational context; ITCertPath does not reproduce confidential exam questions.