Definition of Done (DoD) in Agile: Examples [2026]

A. Togay Koralturk A. Togay Koralturk, Best-Selling PMP Author Last updated on August 23, 2026 9 min read

Ask five people on a team whether a task is "done" and you can get five different answers — coded, tested, reviewed, deployed, or just "it works on my machine." The definition of done exists to end that argument before it starts: one shared checklist that turns a vague word into an agreed, verifiable standard. This guide explains the definition of done in full — what it is, real examples, who owns it, how it differs from acceptance criteria and the definition of ready, and how it is tested on the PMP and CAPM exams.

What is the definition of done?

The definition of done (DoD) is a shared, formal checklist of the criteria a piece of work must satisfy to be considered complete and potentially releasable. It is the team's agreed answer to "what does 'done' actually mean here?" — a quality bar every backlog item, story, or increment must clear before anyone calls it finished.

Its defining trait is that it is team-wide: the same definition of done applies to every item, not a different one per task. In Scrum it is a commitment attached to the Increment, and its purpose is transparency — everyone, from developers to stakeholders, shares one honest understanding of what "done" means, so no one mistakes half-finished work for a shippable result. Anything that does not meet the definition of done is simply not done, which is what gives the term its power.

Definition of done examples

A definition of done is usually a short checklist the team can run through for any item. The exact contents vary by team and product, but a typical software definition of done looks like this:

  • Code written and peer-reviewed — the work is implemented and a second person has reviewed it.
  • Tests written and passing — unit and integration tests exist and pass.
  • Acceptance criteria met — the specific criteria for the story are satisfied.
  • Documentation updated — any user or technical docs reflect the change.
  • Merged and the build passes — the code is integrated and the pipeline is green.
  • No known critical defects — no open blocker or critical bugs remain.
  • Accepted by the Product Owner — the Product Owner agrees it meets the goal.

Notice that a good definition of done reaches beyond "the code works" to cover testing, documentation, and integration — the things that make work actually shippable rather than just written. A team new to the practice often starts with a short list and strengthens it over time as it learns what "done" really requires.

Who owns the definition of done?

The team owns the definition of done — in Scrum, the developers create and maintain it, with the whole Scrum Team aligned on it. It is not handed down by a manager or dictated by the Product Owner; the people who do the work define the standard their work must meet, which is what makes them accountable to it.

There is one nuance the exam likes. If the organization has an organizational standard — a minimum definition of done that all teams must meet, common in regulated or large enterprises — then the team must satisfy that minimum and may make its own definition stronger, but not weaker. So ownership sits with the team, within any floor the organization sets. This keeps the standard both locally meaningful and organizationally consistent.

Definition of done vs. acceptance criteria

The definition of done and acceptance criteria are constantly confused, and the difference is one of the most useful things to get straight. The definition of done is a team-wide quality bar that applies to every item; acceptance criteria are specific conditions for one story that describe what that particular story must do. Here is the comparison:

Definition of done Acceptance criteria
Applies to Every backlog item (team-wide) One specific story
Defines The quality and completeness bar What that story must do
Who sets it The team (developers own it) The Product Owner, with the team
Changes The same across the backlog Different for every story

The key rule: a story is done only when it meets both its acceptance criteria and the definition of done. Meeting the acceptance criteria proves the story does what it should; meeting the definition of done proves it was built to the team's quality standard. Skipping either one means the work is not actually finished.

Definition of ready (DoR) and DoR vs. DoD

The definition of ready (DoR) is the definition of done's counterpart at the other end of the sprint. It is a checklist of criteria a backlog item must meet before the team pulls it into a sprint — that it is clearly described, understood, estimated, small enough, and free of blockers. Where the definition of done is an exit gate, the definition of ready is an entry gate.

The clean way to remember the pair: the definition of ready asks "is it ready to start?"; the definition of done asks "is it ready to ship?"

Definition of ready (DoR) Definition of done (DoD)
When it applies Before a story enters the sprint Before a story is called complete
The question Is it ready to start? Is it ready to ship?
Typical checks Clear, estimated, no blockers Coded, tested, documented, accepted

One difference worth noting: the definition of done is a formal commitment in Scrum, while the definition of ready is a widely used optional practice, not an official Scrum artifact. Used together, they keep well-formed work flowing in and only genuinely finished work flowing out.

Why the definition of done matters

The definition of done matters because it converts a subjective word into an objective standard, and that has real consequences. Without it, "done" drifts: one developer means "code written," another means "tested and deployed," and the gap surfaces as bugs, rework, and missed expectations late in the game.

With a clear definition of done, three things hold. Quality is consistent, because every item clears the same bar. Transparency is real, because stakeholders can trust that "done" means shippable, not half-built. And velocity is honest, because only work that truly meets the definition of done is counted — so the team's velocity reflects finished work, not optimistic guesses. A vague definition of done quietly corrupts all three.

Definition of done on the PMP® and CAPM® Exams

Agile and hybrid approaches make up a large share of the PMP exam, so the definition of done is firmly in scope. The facts to lock in: it is a team-wide, shared standard of quality and completeness; the team (the developers) owns it; and work that does not meet it is not done and is not counted as complete. The exam also tests the distinction from acceptance criteria — team-wide bar versus per-story conditions — since confusing the two is a classic error.

Situational questions usually present work that meets its acceptance criteria but not the definition of done, and reward recognizing that it is therefore not finished. The CAPM tests the same ideas a little more directly, often defining the term or distinguishing it from the definition of ready. Because agile shows up throughout the exam, our PMP Complete Study Guide, the most complete on the market, covers the Scrum artifacts and their commitments so these distinctions are second nature.

PMP Practice Question: Definition of Done

A project manager oversees a hybrid medical-device project in which a Scrum team builds the device's companion software. The company's quality policy sets an organizational minimum for the definition of done: every increment must include traceability records linking code changes to requirements. During audit preparation in sprint 4, the project manager discovers that the team's own definition of done omits traceability, and that 5 backlog items already declared done have no such records. The team lead objects that the developers own the definition of done and have deliberately tailored it for speed.

What should the project manager do next?

a) Respect the team's definition of done, since the developers own it, and record the traceability requirement as a recommended practice for future sprints.

b) Have the definition of done strengthened to include traceability from the next sprint forward, leaving the 5 items as done because they met the definition in force when they were finished.

c) Have the definition of done corrected to include the organizational minimum, and treat the 5 items as NOT done until their traceability records exist.

d) Escalate to the quality department to rule on whether the traceability policy applies to agile teams before changing anything.

Correct answer: C.

Rationale: The team owns its definition of done, but only within the floor the organization sets: where an organizational standard exists, a team may make its definition stronger, never weaker, so the tailored-for-speed version was invalid from day one. That is what defeats the tempting choice b): this is not a rule change being applied retroactively, because the traceability minimum was in force all along — the 5 items never met the required standard and were simply misclassified, and in a regulated product that gap is precisely what an audit will find. Choice a) repeats the team lead's half-truth about ownership and quietly converts a mandatory quality requirement into a suggestion, while choice d) escalates a question the quality policy has already answered, delaying a correction the project manager owns. To face more questions where ownership and process collide like this, work through our PMP practice exams or, at the entry level, our CAPM practice exams.

Frequently asked questions

What is the definition of done?

The definition of done is a shared, formal checklist of the quality and completeness criteria a piece of work must meet to be considered done and potentially shippable. It applies team-wide to every backlog item, so everyone shares one standard for what "done" means. Work that does not meet the definition of done is not done.

What is an example of a definition of done?

A typical software definition of done is a checklist such as: code written and peer-reviewed, unit and integration tests written and passing, acceptance criteria met, documentation updated, code merged with a passing build, no known critical defects, and accepted by the Product Owner. Each team tailors the list, but it always reaches beyond "the code works" to what makes work shippable.

Who defines the definition of done?

The team owns the definition of done — in Scrum, the developers create and maintain it, with the whole Scrum Team aligned. It is not set by a manager or the Product Owner. If the organization imposes a minimum organizational definition of done, the team must meet that floor and may make its own stronger, but never weaker.

What is the difference between the definition of done and acceptance criteria?

The definition of done is a team-wide quality bar that applies to every backlog item, while acceptance criteria are specific conditions for a single story describing what it must do. A story is done only when it satisfies both: its acceptance criteria confirm it does the right thing, and the definition of done confirms it was built to the team's standard.

What is the difference between the definition of ready and the definition of done?

The definition of ready is an entry gate — criteria a story must meet before it enters a sprint, answering "is it ready to start?" The definition of done is an exit gate — criteria for calling work complete, answering "is it ready to ship?" The definition of done is a formal Scrum commitment; the definition of ready is a common optional practice.

Is the definition of done on the PMP exam?

Yes. Agile and hybrid approaches are a large part of the PMP exam, and the definition of done is in scope. You are expected to know that it is a team-wide standard of quality and completeness, that the team owns it, that work not meeting it is not done, and how it differs from acceptance criteria and the definition of ready.

Is the definition of done on the CAPM exam?

Yes. The CAPM covers agile concepts including the definition of done, usually a little more directly than the PMP — often defining the term or distinguishing it from the definition of ready or acceptance criteria. Because the CAPM is scenario-based, you should still be ready to apply the idea in a short situation.

A cross-functional team collaborating around a task board, representing the Scrum framework in action.

What Is Scrum? Roles, Events & Artifacts [2026]

A. Togay Koralturk August 23, 2026 12 min read

Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.

A scrum master facilitating an agile team at a board, coaching rather than directing the work.

Scrum Master: Role, Responsibilities & Skills [2026]

A. Togay Koralturk August 23, 2026 12 min read

A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.

A product owner presenting priorities to an agile team beside a board of backlog items.

Product Owner: Role, Responsibilities & Skills [2026]

A. Togay Koralturk August 23, 2026 11 min read

The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.

About the Author

A. Togay Koralturk is a globally recognized pioneer and educator in project management and sustainable design and construction, a best-selling author, and an entrepreneur. His publications have reached hundreds of thousands of professionals worldwide and have been extensively adopted as primary course material in universities throughout the United States. Holding a bachelor’s degree in civil engineering and a master’s degree in construction management from the University of Southern California, he has played a pivotal role in leading numerous construction projects ranging from $100 million to $500 million worldwide, and he has educated thousands of professionals. Continuing his professional journey, he founded Projeric and Projectific, where he serves as the instructor and CEO.