CAPM Definition of Done, Acceptance Criteria, and Team Agreements

Definition of done and acceptance criteria solve different adaptive problems. CAPM often tests the distinction directly because teams lose transparency quickly when they report work as done without shared completion rules or without clear item-level success conditions.

What Each One Does

Definition of done is the broader team-wide completion standard. It says what must be true before work can honestly be reported as complete.

Acceptance criteria are item-specific. They describe what must be true for one backlog item, story, or feature to be considered acceptable.

Team agreements sit alongside both. They define the practical norms for how the team collaborates, communicates, manages recurring expectations, and handles routine workflow situations.

These are related, but they are not interchangeable.

Why CAPM Cares About The Distinction

If the team says an item is done while testing is still open, that is usually a definition-of-done problem. If stakeholders disagree about how a specific story should behave, that is usually an acceptance-criteria problem. If the team keeps stumbling over unclear collaboration expectations, handoff norms, or meeting behavior, that is often a team-agreement problem.

The strongest CAPM answer usually fixes the right layer instead of treating every problem as the same kind of ambiguity.

Acceptance Criteria Versus Definition Of Done

This table matters because CAPM often puts two of these in the same scenario and asks you to notice which one is actually weak.

Completion Logic

    flowchart LR
	    A["Backlog item"] --> B["Acceptance criteria clarify item success"]
	    B --> C["Work is developed and checked"]
	    C --> D["Definition of done is satisfied"]
	    D --> E["Item can honestly be reported as done"]

The key thing to notice is that meeting acceptance criteria for one item is not always enough if the team’s broader completion standard has not been met.

Why Team Agreements Matter

Team agreements do not define product behavior. They define how the team works. They may cover:

• meeting norms
• review expectations
• communication practices
• how blockers are surfaced
• how handoffs are handled
• how quality and collaboration expectations stay visible

CAPM sometimes tests this indirectly. A team may keep losing time because its working assumptions are inconsistent, even though the backlog itself is fine. That is not always a product-definition problem. It may be a team-agreement problem.

What Good Adaptive Completion Looks Like

Strong adaptive delivery usually has:

• clear acceptance criteria before work starts
• a definition of done that protects transparency and quality
• team agreements that reduce repeated coordination friction
• a refusal to call work “done” when meaningful completion work is still open

Weak adaptive delivery often does the opposite:

• acceptance expectations are vague
• different people mean different things by done
• team norms are mostly implied rather than explicit
• pressure encourages “almost done” to be reported as done

Example

A team says a story is done because coding is finished. But testing, peer review, and documentation are all required by the team’s shared completion rule, and the story never clearly stated how invalid inputs should behave. That means more than one problem may exist:

• the unfinished testing and documentation point to a definition-of-done problem
• the unclear invalid-input behavior points to an acceptance-criteria problem

CAPM usually rewards candidates who separate those layers correctly.

Exam Scenario

When CAPM gives you a completion or quality scenario, ask:

1. Is the problem about one backlog item’s expected behavior?
2. Is the problem about the team-wide meaning of done?
3. Is the problem about how the team coordinates its work?
4. Is someone using “done” to mean “almost ready”?

Those questions usually reveal the strongest answer.

Common Pitfalls

• treating done as a personal opinion instead of a shared team standard
• confusing acceptance criteria with the broader completion rule
• using “done” to mean “almost done”
• skipping team agreements and then wondering why coordination stays inconsistent
• assuming definition of done can replace item-specific acceptance clarity

Check Your Understanding

Sample Exam Question

Scenario: During a review, one team member says a story is done because coding is complete. Another says testing and documentation are still open. Stakeholders also say the story never clearly stated how invalid inputs should behave. The team also admits it has no shared agreement for how blockers and handoffs should be surfaced during the sprint.

Question: What does that review discussion show?

• A. The issue is only backlog prioritization
• B. The story should be counted as done because development is finished
• C. The disagreement proves agile teams should avoid shared standards
• D. The team is dealing with both a definition-of-done problem and an acceptance-criteria problem

Best answer: D

Explanation: CAPM usually rewards distinguishing the layers correctly. The unfinished testing and documentation point to definition of done, while unclear expected behavior points to weak acceptance criteria.

Why the other options are weaker:

• A: Priority is not the main issue here.
• C: The disagreement shows why shared standards matter.
• B: Coding alone is not enough when the agreed completion standard is broader.