Four terms show up across the PMP exam's agile and hybrid content, and candidates routinely treat them as synonyms: acceptance criteria, Definition of Done, Definition of Ready, and success criteria. They are not synonyms. They sit at different levels, they are agreed at different times, and different people own them.
This matters more than vocabulary trivia, because situational questions are usually built on exactly this distinction. A question describes a team arguing about whether something is finished, and the correct answer depends on whether the dispute is about one item's requirements, the team's shared quality bar, or the project's overall benefit. Pick the wrong level and you pick the wrong answer.
The Four Terms, Side by Side
| Term | Level | Scope | Typically agreed |
|---|---|---|---|
| Acceptance criteria | One deliverable or backlog item | Unique to that item | Before work on the item begins |
| Definition of Done | All work the team produces | One standard applied to everything | Once, by the whole team, then refined |
| Definition of Ready | One item, before it starts | Readiness to begin, not completion | During refinement, before planning |
| Success criteria | The whole project | Benefit, cost, schedule, satisfaction | In the charter, at initiation |
Read the table column by column rather than row by row. The thing that separates these terms is the level they apply to and the direction they point: acceptance criteria and Definition of Done look backward at whether work is finished, Definition of Ready looks forward at whether work can start, and success criteria ignore individual deliverables entirely.
Acceptance Criteria: Per Item, Agreed Up Front
PMI's long-standing definition is narrow and useful: acceptance criteria are the set of conditions that must be met before a deliverable is accepted. Two words in that sentence carry weight.
Conditions means they are testable. A well-formed acceptance criterion resolves to pass or fail, not to a judgment call. "The report loads quickly" is not an acceptance criterion. "The report returns results for a 12-month range" is.
Deliverable means they are specific to one item. Every backlog item or deliverable carries its own set, written for that item and no other. This is the single most reliable way to tell acceptance criteria apart from a Definition of Done on the exam: if the standard would read differently for a different item, it is acceptance criteria.
They are also agreed before the work starts, with stakeholder input rather than by the development team alone. The product owner or business representative brings the business view of what the item has to do. A question in which a team discovers acceptance criteria only at review time is describing a process failure, not a normal sequence.
Definition of Done: One Bar for Everything
The Definition of Done is a shared understanding among team members of what makes any item complete. The key words are "shared" and "any."
It is owned by the whole team, not by the product owner, and it applies uniformly to all work rather than item by item. Typical contents are intrinsic to the work itself: tests written and passing, defects at an agreed threshold, documentation updated, code reviewed, the increment integrated.
So an item is only genuinely finished when it satisfies both its own acceptance criteria and the team's Definition of Done. Those are two separate gates, and exam questions exploit the gap between them. An item that meets every acceptance criterion but skipped the regression tests the Definition of Done requires is not done. The honest answer is that it does not go into the increment, not that the team makes an exception this once.
Definition of Ready: Optional, and Easy to Overdo
The Definition of Ready is the odd one out. It describes what an item needs before the team will pull it into a sprint, and it typically points at things outside the item: dependencies resolved, information available, the item refined and sized, the team able to finish it in one iteration.
Two things are worth knowing. First, it is optional and sits outside the Scrum Guide, unlike the Definition of Done. Treating it as mandatory is a mistake. Second, a heavy Definition of Ready can cause real harm by delaying work while the team chases a checklist. If a question presents a team blocked from starting anything because items keep failing a long readiness checklist, the problem is usually the checklist.
Acceptance criteria and the Definition of Ready are related in one direction only: having acceptance criteria drafted is often itself a readiness condition. That does not make them the same thing. Readiness asks whether work can start; acceptance criteria describe what finishing looks like.
Success Criteria: The Project, Not the Deliverable
Success criteria operate at a different altitude. They describe whether the project as a whole achieved what it was funded to achieve, in terms such as cost, schedule, customer satisfaction, and realized benefit. Their scope is broader than acceptance criteria, and the charter is where they belong, along with how success will be measured, by whom, and how often.
The practical consequence is the one candidates miss: a project can deliver every item to its acceptance criteria, pass the Definition of Done on all of it, and still fail its success criteria. Delivering the agreed scope on time does not prove the business case. If a question describes a product that shipped exactly as specified while the expected benefit never appeared, it is pointing at success criteria, not at acceptance.
Reading the Clue Words
Scenario questions rarely name the term. They signal it.
- "The customer refuses to sign off on this feature" points at acceptance criteria for that item.
- "The team disagrees about whether the work is complete" points at the Definition of Done.
- "Items keep getting pulled into the sprint without enough detail" points at the Definition of Ready.
- "The sponsor is questioning whether the project was worth the investment" points at success criteria.
- "Who should agree to this?" separates them by owner: stakeholders and the product owner for acceptance criteria, the whole team for the Definition of Done, the sponsor and charter for success criteria.
Three Traps
Letting the team set acceptance criteria alone. The team owns its Definition of Done. It does not unilaterally decide what the business will accept.
Changing the standard to make something pass. Loosening a Definition of Done to get an item accepted, or quietly dropping an acceptance criterion, is almost never the keyed answer. Making the gap visible is.
Answering at the wrong level. The most common error on these questions is a technically sensible action aimed at the wrong altitude. Before choosing, say to yourself which of the four the scenario is actually about.
Why This Is Worth the Time
The exam has been moving toward judgment for a while. In the update that launched on 9 July 2026, PMI raised the Business Environment domain from 8% to 26% and added case-based and graphic-based question formats, with more questions built around real project artifacts. Questions of that shape reward candidates who can place a situation at the right level quickly, and punish candidates who recognize a term without knowing what it governs.
These four terms are a small piece of the syllabus with an outsized presence in scenario items. Learn the level each one sits at, and a whole category of questions stops being a coin flip.
Sources consulted on 28 October 2026: PMI's blog post on the 2026 PMP exam change; Scrum Alliance on Definition of Ready versus Definition of Done; PremierAgile on Definition of Ready versus acceptance criteria; and a Whizlabs PMP article citing PMI's PMBOK definition of acceptance criteria.