September 7, 2026 · 8 min read
TL;DR: The definition of done appears in 20 answer options across the bank and is keyed 13 times. It wins when the question is whether work is really finished, whether a standard is being applied consistently, or whether an obligation can be built into every item so it cannot be traded away. It loses in seven places, and the most instructive of them is the customer who rejects three reviews running: the definition of done is the team's standard, and the customer is applying a different one.
Candidates learn the definition of done as vocabulary. The exam tests it as a decision: is the problem in front of you a problem about what finished means?
When the stem describes work that was called complete and turned out not to be, or a standard that is not being applied the same way twice.
Defects from features marked done. A customer reports defects in features the team marked done two iterations ago, and the team does write and run tests for each feature. The keyed answer names what is missing: a shared, agreed definition of done the whole team applies consistently before a feature is marked complete. A longer iteration gives more time to apply the same inconsistency. A separate tester role does not by itself define what passing means. The explanation draws the distinction cleanly: testing is necessary, but without a shared statement of what tested covers, one member's idea of complete differs from another's.
A stakeholder rejecting deliverables. Deliverables are failing the main stakeholder's quality specifications and the schedule index has fallen from 0.98 to 0.72. Keyed is reinforcing the definition of done during sprint planning so the team shares a common understanding of expectations. The choice is preventive rather than remedial, which is what the stem asks for, and it forces the disagreement about what done means to surface when it costs a conversation instead of an iteration.
Checking that work is genuinely finished. A team has beaten its planned story count three iterations running. Keyed is checking the completed work against the definition of done. Reading every test result duplicates the team's own quality work, and whether the product owner is satisfied is a separate question from whether the work is complete.
Making an obligation untradeable. A council's parking app is bound by an accessibility standard, and the product owner has moved the accessibility stories down five iterations running. Keyed is writing the standard into the definition of done so that no story is finished without it. The explanation is the rule: an obligation that competes for priority against features loses whenever the features look more valuable, and building it into what finished means takes it out of the queue. The same move keys for a long tail of short admin tasks that each depend on an unpredictable event: build them into the definition of done or the acceptance criteria so they finish alongside the work that triggers them.
Acceptance and scope. As a customer prepares to accept a final deliverable, keyed is an agreed definition of done to accept it against, because without one acceptance has no criteria and becomes a matter of opinion. A project manager new to agile wants to prevent scope creep, and keyed is running workshops with all stakeholders to create the charter and define the definition of done, because scope creep takes hold when nobody can say precisely when something is finished.
Looking backwards. A fix that solved a weeks-old problem later broke another function. The keyed pair examines the gaps in the definition of done that let it through and asks the team member to explain the reasoning and the lesson. Warning them off risky initiatives discourages the behaviour that solved the original problem.
When the disagreement is with the customer, when the question is about a sprint or a release rather than an item, or when the constraint is timing rather than completeness.
The gap is with the customer. Three sprint reviews in a row, the customer is dissatisfied. Cross-checking the definition of done is offered, and so is checking every story against its acceptance criteria. Both lose to bringing the customer and the team together to clarify expectations, because both measure the team against its own standard, which is plainly not the standard the customer is applying.
The question is about a different boundary. A new team member asks what marks a sprint as finished. Every backlog item meeting the definition of done is offered and loses: the sprint ends when its fixed timebox runs out, whatever the state of the work, and the definition of done applies to a single item, not to the sprint. Asked when closing activities begin on an iteration-based project, after the definition of done is met is offered and loses to at the time of a release, which often spans several iterations.
The constraint is timing, not completeness. An increment is ready but would land on branch staff in the same fortnight as a new till platform. Adding a branch-readiness check to the definition of done is offered and loses to agreeing a release date with the other two programmes. The explanation says why: a readiness check records that branches are not ready without changing why.
Common trap: using the definition of done to answer a question about the customer's expectations. Acceptance criteria and the definition of done are both standards. The bank keys the definition of done as the team's shared quality gate, agreed by the team, applied by the team. When the stem says the customer disagrees with the team about what good looks like, no amount of checking against the team's own bar closes that gap. The bank explains this rather than just marking the option wrong, and the wording is worth carrying: the customer is applying a different standard, so go and find out what it is.
Ready governs what enters an iteration, done governs what leaves it, and acceptance criteria say whether one feature does what was asked.
| Concept | Governs | Belongs to | Agreed when |
|---|---|---|---|
| Definition of ready | Work entering an iteration | The team | Before work starts |
| Acceptance criteria | Whether a specific feature does what was asked | Agreed with the requester | Before work starts, as part of ready |
| Definition of done | Work leaving an iteration | The team | Before work starts, applied at completion |
The bank tests the boundary directly. Features serving different user profiles need different acceptance criteria, and the keyed answer reviews each feature's acceptance criteria as part of its definition of ready and places the matching tests in its definition of done. Reversing the two is the distractor. On a hybrid project needing a single network diagram, the keyed pair combines the agile track's definition of done with the predictive track's exit criteria, and its definition of ready with the predictive dependency milestones: what counts as finished, and what counts as ready to start, stated in terms both tracks recognise.
The bank also makes a point of who writes it. Defining done and ready is team or product work, not part of acquiring resources, and when a team charter already covers vision, meeting times and behaviour, agreeing the definition of done is the keyed next step, because it belongs in the charter as a working agreement the team holds itself to.
When is the definition of done the keyed answer on the PMP exam? When the question is whether work is genuinely finished, why defects are reaching the customer from features marked done, how to stop an obligation being deferred sprint after sprint, or what a deliverable can be accepted against. It is the team's agreed checklist of what must be true before anything is called complete.
When is the definition of done the wrong answer? When the customer is dissatisfied with what the team built. The definition of done is the team's own standard, and checking work against it measures the team against a bar the customer is plainly not applying. The keyed answer in that case is a conversation between the customer and the team.
What is the difference between the definition of done and the definition of ready? Ready governs work entering an iteration; done governs work leaving it. Acceptance criteria are agreed before work starts, so they belong to the definition of ready. The tests that prove them gate completion, so they belong to the definition of done.
Does meeting the definition of done end the sprint? No. A sprint ends when its timebox elapses. Unfinished items return to the product backlog, and the definition of done is a test applied to individual items, not to the sprint.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Acceptance Criteria: The Scope Answer Candidates Skip Past and Quality on the PMP Exam: Prevention, Inspection, and the Cost of Getting It Wrong. Scope and quality tasks are mapped on the Process domain study page.
When is the definition of done the keyed answer on the PMP exam?
When the question is whether work is genuinely finished, why defects are reaching the customer from features marked done, how to stop an obligation being deferred sprint after sprint, or what a deliverable can be accepted against. It is the team's agreed checklist of what must be true before anything is called complete.
When is the definition of done the wrong answer?
When the customer is dissatisfied with what the team built. The definition of done is the team's own standard, and checking work against it measures the team against a bar the customer is plainly not applying. The keyed answer in that case is a conversation between the customer and the team.
What is the difference between the definition of done and the definition of ready?
Ready governs work entering an iteration; done governs work leaving it. Acceptance criteria are agreed before work starts, so they belong to the definition of ready. The tests that prove them gate completion, so they belong to the definition of done.