Definition of Done vs. Acceptance Criteria: How to Tell the Difference on the PMP Exam

September 25, 2026 September 21, 2026

admino

A feature can meet its acceptance criteria and still not be done.

A team can complete its normal quality activities and still deliver something that fails a specific customer requirement.

That is why Definition of Done and Acceptance Criteria can be easy to confuse in PMP® scenario questions.

They are related, but they answer different questions:

Acceptance Criteria: Does this specific item meet the conditions required for acceptance?
Definition of Done: Has the work met the agreed standard for being complete?

The important reasoning question is:

Is the scenario testing whether the item meets its specific requirements—or whether the work is genuinely complete?

1. Start With the Core Difference

Acceptance Criteria

Ask:

What must this particular requirement, story, feature, or deliverable satisfy to be accepted?

Acceptance criteria are specific to the item being delivered. They may describe:

required behavior,
business conditions,
expected outputs,
user-visible functionality,
performance expectations,
specific validation conditions.

In other words, acceptance criteria help determine whether the particular outcome meets what was expected.

Definition of Done

Now ask:

What must be true before the work can legitimately be considered complete?

The Definition of Done provides a shared completion standard. Depending on the project environment, it may include expectations such as:

development completed,
testing completed,
defects addressed,
documentation updated,
reviews performed,
quality standards satisfied,
integration completed,
required compliance activities completed.

The distinction is therefore:

Acceptance Criteria = item-specific conditions

Definition of Done = shared completion standard

2. A Feature Can Meet Its Acceptance Criteria and Still Not Be Done

Consider:

A software feature performs exactly as requested and satisfies all of its acceptance criteria. However, required regression testing has not been completed and the documentation has not been updated.

Has the feature satisfied its acceptance criteria?

Yes.

Is the work necessarily done?

No.

If testing and documentation are part of the agreed Definition of Done, the work remains incomplete.

The functionality may be correct, but the full completion standard has not yet been satisfied.

This is an important distinction:

Meeting acceptance criteria does not automatically mean all work required for completion has been performed.

3. The Opposite Can Also Happen

Now consider the reverse:

The team completes development, testing, peer review, integration, and documentation. During review, however, the customer discovers that one required business condition is missing.

The team may have completed its normal workflow and quality activities.

But the item still fails a specific condition required for acceptance.

So technical or procedural completion does not automatically mean the required outcome has been achieved.

Completing the standard workflow does not guarantee that the specific acceptance conditions were met.

The two concepts work together.

4. Acceptance Criteria Are Specific to the Item

Imagine a team is developing an order-tracking feature.

One acceptance criterion might state:

When a customer enters a valid order number, the system displays the current order status within two seconds.

That criterion is specific.

It tells us something this particular feature must do.

Another feature might have completely different acceptance criteria.

This is why acceptance criteria often vary across requirements, stories, features, or deliverables.

When a PMP scenario focuses on whether a specific expected condition or outcome has been satisfied, acceptance criteria should be on your radar.

5. Definition of Done Creates a Shared Standard

Now imagine the same team agrees that work cannot be considered done until:

required functionality is completed,
tests pass,
security checks are completed,
documentation is updated,
integration succeeds,
critical defects are resolved.

These expectations provide a shared meaning of done across relevant work.

The specific functionality may change from one item to another.

The completion standard is broader and more consistent.

This creates transparency.

When the team says something is “done,” stakeholders should have a common understanding of what that means.

6. The Two Concepts Work Together

Acceptance Criteria and the Definition of Done are not competing concepts.

They address different dimensions of completion.

A useful way to think about them is:

Acceptance Criteria ask: Did this item satisfy its specific conditions?

Definition of Done asks: Has all work required for completion been satisfied?

Acceptance criteria can contribute to determining whether an item is complete, but they do not necessarily represent the entire Definition of Done.

A deliverable may therefore need to satisfy both before it can genuinely be considered complete and acceptable.

7. Scenario: The Feature Works, but Testing Is Incomplete

Consider:

A product owner confirms that a feature provides the expected functionality. However, regression testing required by the team's Definition of Done has not been completed.

Two answers remain:

A. Mark the feature as done because the expected functionality has been accepted.

B. Complete the remaining regression testing required by the Definition of Done.

The important clue is not whether the feature works.

It does.

The problem is that part of the agreed completion standard remains unsatisfied.

Therefore, functional acceptance alone does not make the work done.

8. Scenario: Everything Is Complete Except One Requirement

Now consider:

The team completes development, testing, integration, and documentation. During review, the customer identifies that the feature does not support one required transaction type.

What is missing?

Not the team's normal completion activities.

The missing element is a specific required condition.

That points toward the acceptance criteria.

The team should not assume that completing its normal workflow means every requirement has been satisfied.

9. Don't Confuse Them With Definition of Ready

A third concept sometimes appears in agile scenarios: Definition of Ready.

Keep the three questions separate:

Definition of Ready:
Is the work sufficiently understood and prepared to begin?

Acceptance Criteria:
What specific conditions must this item satisfy?

Definition of Done:
What must be true before the work is considered complete?

A useful mental sequence is:

Ready → Can we begin?
Acceptance Criteria → What must this item satisfy?
Done → Is the work complete?

Do not let the third concept obscure the main distinction between acceptance and completion.

10. Definition of Done Is Not Just About Coding

Although Definition of Done is frequently discussed in software and agile environments, the underlying idea is broader than coding.

A completion standard might include:

regulatory documentation,
operational readiness,
training materials,
security approval,
deployment preparation,
audit evidence,
quality verification.

So when reading a scenario, don't ask only:

“Has development finished?”

Ask:

“What does complete mean in this project environment?”

The Project Reasoning Lab Two-Lens Test

When a PMP scenario mentions acceptance, completion, quality, or “done,” examine it through two lenses.

Lens 1: The Item Lens

Ask:

What was this item supposed to accomplish?
What specific conditions must it satisfy?
Does the result meet those conditions?

If the problem concerns the specific expected outcome, think:

Acceptance Criteria

Lens 2: The Completion Lens

Ask:

Has all required work been completed?
Have the necessary quality activities occurred?
Have testing, documentation, integration, or other agreed standards been satisfied?
Can the team legitimately call the work complete?

If the problem concerns the overall completion standard, think:

Definition of Done

Then ask one final question:

Could the item pass one lens but fail the other?

That is often where the PMP scenario becomes much easier.

Quick Comparison

Acceptance Criteria	Definition of Done
Specific to a requirement, story, feature, or deliverable	Shared completion standard for relevant work
Defines conditions for acceptance	Defines conditions for completion
May vary from item to item	Provides a consistent standard across applicable work
Focuses on the expected result or behavior	Focuses on overall quality and completeness
Asks: Does this item meet its specific conditions?	Asks: Is this work genuinely complete?
Can be satisfied while other required completion work remains	Completion activities can be performed while a specific acceptance condition remains unmet