September 6, 2026 · 8 min read
TL;DR: Acceptance criteria are keyed 9 times in this bank's scope slice and appear as a distractor twice, the best ratio in the topic. The scenarios that key them share a shape: a deliverable meets the written requirements and somebody still will not accept it, or an item cannot be estimated because nobody has said what finished means. The keyed answer builds the checkable standard rather than arguing about the requirement.
A vendor delivers a customer-facing reporting module. It meets every requirement in the agreed scope statement. At the acceptance walkthrough the customer's business owner refuses to sign off, saying the reports are technically correct but not what a finished product looks like. Three of the four options treat this as a dispute to be won or deferred. Only one treats it as a missing definition.
A shared standard for finished. That is what acceptance criteria are, and the exam keys them in exactly the situations where their absence is what caused the argument.
In the reporting module question, the options are: point to the signed scope statement and ask the sponsor to overrule the business owner, work with the business owner to define specific, checkable acceptance criteria and re-present the deliverable against them, log the objection as a risk and move on to the next module, or add the concerns to the requirements documentation and re-baseline scope.
The keyed answer defines the criteria. The explanation puts the whole topic in one sentence: the requirements are not the problem, what is missing is a shared checkable standard for what finished means, and defining it converts an unfalsifiable objection into something that can be tested.
Look at why the other three fail, because each is a distinct error the bank punishes elsewhere too. Escalating to the sponsor tries to win an argument that documentation cannot settle, since the business owner is not claiming a requirement was missed. Logging it as a risk defers something that has already happened, which makes it an issue rather than a risk. Re-baselining scope treats vague dissatisfaction as a change, spending baseline authority on an objection nobody has made concrete.
Common trap: reading "it meets the signed requirements" as proof the project manager is right. It usually is a true statement, and this bank offers it as a distractor precisely because it is true and useless. Requirements state what to build; acceptance criteria state how anyone checks it was built. A deliverable can satisfy the first and fail the second, and when it does, producing the signed document is the option the explanations describe as arguing rather than solving.
In the project scope statement, in the definition of ready before estimating, and in the definition of done for anything that must finish alongside other work. The exam tests all three placements.
| Question shape | Keyed answer | What the distractors do |
|---|---|---|
| Which is not a purpose of the project charter? | Stating product acceptance criteria (they belong to the scope statement) | Offer real charter purposes: authorizing the PM, establishing the project |
| Backlog items ordered but not estimated | Add acceptance criteria to the definition of ready first | Estimate by analogy, or have the product owner estimate |
| Admin tasks ageing in the backlog | Build them into the definition of done or the acceptance criteria | Re-prioritize daily, or bundle them into their own stories |
| Developer hits ambiguous criteria mid-iteration | Collaborate with the product owner | Escalate to a steering committee, ask the architect, poll the team |
| Deliverable meets requirements, owner will not sign | Define checkable criteria, re-present against them | Escalate to the sponsor, log a risk, re-baseline |
The charter question catches more candidates than it should. It asks which of four items is not a purpose of the project charter, offering the product acceptance criteria, high-level stakeholder requirements, establishing the existence of the project, and authorizing the project manager. The acceptance criteria are keyed as the exception, because they belong to the scope statement. The charter says the project exists and who runs it; the scope statement says what the project will produce and how anyone will know it is right.
The definition-of-ready question is subtler and more practical. New backlog items have been ordered but not estimated, and the product owner wants tests written that verify each item's particular properties. The keyed answer adds those as acceptance criteria to the definition of ready before any estimating starts, and the explanation gives the reason plainly: an item cannot be estimated sensibly until it carries them. Estimating something whose finish condition is undefined is guessing at the size of an unknown.
The product owner, and the exam is strict about it.
A developer working an iteration hits ambiguity in a feature's acceptance criteria. The options are call a steering committee meeting, raise it at the next team meeting for collective input, send it to the technical architect for an expert interpretation, or collaborate with the product owner to resolve it.
The keyed answer goes to the product owner. The explanation draws a line worth carrying into the exam: acceptance criteria are the product owner's statement of what done and correct mean for a feature, so ambiguity in them is not a technical question with a technical answer, it is a gap in what the customer's representative intended, and only they can close it.
That is the same principle behind the three C's question in this bank. You have created the card with the requirement, its criticality and the acceptance criteria, and the question asks what comes next under Card, Conversation, Confirmation. Putting it on the board, prioritizing it into a sprint and briefing the sponsor are all offered. The keyed answer has the conversation with the developers about how the software will be used and confirms the criteria and the definition of done, because a written requirement is one person's understanding of the need and the conversation is where a shared one gets built.
Across this slice the pattern holds: going back to a stakeholder for clarification is keyed once against 5 appearances as a distractor, because vague asking is not the answer. Working with the right person to produce something checkable is.
What is the difference between a requirement and an acceptance criterion? A requirement says what the deliverable must do. An acceptance criterion says how anyone checks that it does, in terms agreed in advance. A deliverable can meet the first and fail the second.
Where do acceptance criteria live: the charter or the scope statement? The scope statement. The charter establishes the project, authorizes the project manager and states high-level requirements.
What is the difference between definition of ready and definition of done? Ready is what an item must carry before the team takes it on, including its acceptance criteria. Done is the standard every item meets before it counts as complete.
Who resolves ambiguous acceptance criteria on an agile project? The product owner, with the team. The criteria are their statement of what done means, so ambiguity is a gap in intent rather than a technical question.
The scope and requirements questions in this bank are certified against PMBOK 8 and the July 2026 exam content outline, and the explanations name which artifact each wrong option reached for and why it does not settle the question, every wrong answer explained rather than just marked wrong. Start the free 20-question sample with no card and no signup.
Related reading: Project Scope on the PMP Exam and The Work Breakdown Structure. The domain breakdown is on the Process study page.
Sources: PMI, Project Management Professional (PMP) Exam Content Outline
What is the difference between a requirement and an acceptance criterion?
A requirement says what the deliverable must do. An acceptance criterion says how anyone will check that it does, in terms both sides agreed in advance. That gap is what the exam tests. In one question a vendor delivers a module meeting every requirement in the agreed scope statement and the business owner still refuses to sign off, saying it is technically correct but not what a finished product looks like. The requirements were not the problem; a checkable standard for finished was missing.
Where do acceptance criteria live: the charter or the scope statement?
The project scope statement. One question asks which of four items is not a purpose of the project charter and keys the product acceptance criteria, because the charter establishes the project, authorizes the project manager and states high-level stakeholder requirements, while acceptance criteria belong to the scope statement. Charter-versus-scope-statement confusion is a recurring source of lost marks in this slice.
What is the difference between definition of ready and definition of done?
Definition of ready is what a backlog item must carry before a team will take it on, and acceptance criteria belong there because an item cannot be estimated sensibly without them. Definition of done is the standard every item meets before it counts as complete. In one question a long tail of small administrative tasks keeps ageing in the backlog, and the keyed answer builds them into the definition of done or the acceptance criteria so they finish alongside the work that triggers them.
Who resolves ambiguous acceptance criteria on an agile project?
The product owner, with the team. Acceptance criteria are the product owner's statement of what done and correct mean for a feature, so ambiguity in them is a gap in what the customer's representative intended rather than a technical question. In one question a developer hits that ambiguity mid-iteration and the keyed answer collaborates with the product owner, against distractors that convene a steering committee, poll the team, or ask a technical architect to interpret it.