What is the Definition of Done?
The Definition of Done is the checklist a piece of work has to clear before a team can call it finished. The Scrum Guide's November 2020 revision states it formally: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product."
That's the whole definition. No named criteria, no template, no checklist items. The guide leaves the content of the DoD to the organization first, and to the team if no organizational standard exists: if a Definition of Done is part of the standards of the organization, every Scrum Team follows it as a minimum; otherwise the team writes one appropriate to its own product.
What the DoD actually controls is when work counts as real. The guide draws a hard line: "The moment a Product Backlog item meets the Definition of Done, an Increment is born," and "work cannot be considered part of an Increment unless it meets the Definition of Done." A feature that's 90 percent finished (code merged but untested) counts for nothing in the Increment.
For an engineering leader trying to give an honest forecast instead of a hopeful one, that's the whole point: work that isn't done doesn't exist yet, no matter how far along it looks in standup. The rest of the forecasting and delivery material sits in Engineering management guides for CTOs and VPs of Engineering. It's also why the guide ties DoD directly to Sprint forecasting confidence, a link HighCircl's guide to how blended teams plan sprint capacity works through in more detail than fits here.
Definition of Done vs. Definition of Ready
Definition of Ready checks whether a Product Backlog Item is fit to pull into a sprint: are the acceptance criteria clear, is the story sized, are its dependencies known. Definition of Done checks the opposite end of the same item: is the work actually finished. One gates the start of the work, the other gates the end.
"Definition of Ready" isn't a Scrum Guide term. Search the guide's full text and the phrase doesn't appear once. DoR is a practice teams built on top of Scrum, useful for catching badly-formed stories before they eat a sprint, but it carries none of the formal weight the guide gives the Definition of Done. Treat it as optional, worth adopting if your backlog keeps producing stories nobody can start cleanly.
Definition of Done vs. acceptance criteria
Acceptance criteria are written per story: what has to be true for this specific piece of work to satisfy whoever asked for it. A password-reset story's acceptance criteria might require the reset email to arrive within two minutes and the link to expire after one hour. The Definition of Done doesn't care which story it's attached to. It applies the same bar (tests pass, code reviewed, change deployed to staging) to every Product Backlog Item regardless of what it does.
Confuse the two and you get a story that passes every acceptance criterion but ships untested, or a DoD written so specifically for one feature that the next story can't reuse it. Acceptance criteria answer whether you built the right thing. The Definition of Done answers whether you built it properly. A Product Backlog Item needs to clear both before anyone calls it finished.
Definition of Done examples
A single-org software team's DoD is usually short and mechanical: code merged to main, unit tests passing, peer-reviewed by at least one other engineer, deployed to staging, no known critical or high-severity bugs open against it. None of that depends on who wrote the code or where they sit, because on a single-org team, that's a constant.
It stops being a constant the moment part of the roster is nearshore or works for a different company. A blended DoD for that same checklist has to answer questions the single-org version never had to face: who reviews code written by the vendor's engineers, does that reviewer have the same production access the in-house team has, and does "deployed to staging" mean the nearshore engineer can trigger that deploy themselves or has to hand it to someone else. A DoD that just says "peer-reviewed" and leaves those questions to get worked out mid-sprint is really two different DoDs pretending to be one document.
How to write a Definition of Done for a blended in-house and nearshore team
1. Map where "done" already breaks down across the handoff
Before writing anything new, find where the current DoD, formal or informal, already falls apart at the seam between in-house and nearshore work. Ask both sides separately: where does a story stall waiting on the other group, and where has "done" turned out to mean different things depending on who said it. Most of the gaps you need to close already showed up in the last sprint or two.
2. Keep a single DoD for both sides
A vendor team that maintains its own internal quality bar alongside the client's means the DoD has failed. Put the whole checklist (testing, review, deployment, documentation) in one document both sides read from. If your DoD's testing line needs more than "tests pass" to mean the same thing on both sides, a testing strategy that spans an in-house and nearshore team is the place to define what unit, integration, and regression coverage actually means before you put it on the checklist.
3. Name who owns review and sign-off on each side
"The team reviews it" isn't an answer once the team spans two payrolls. Name a specific person on each side: the nearshore lead who reviews before code leaves that group, and the in-house engineer or lead who signs off before it's called done. This is the same ownership question role and structure decisions on an agile team already force you to answer; the DoD is just where that answer gets written down and enforced.
4. Put the DoD where both sides actually see it
A DoD living in a wiki the vendor's engineers can't access, or a Jira workflow field only your in-house team sees, is a private standard dressed up as a shared one. Put it somewhere both sides open daily, and check access explicitly when a new engineer joins either group instead of assuming the invite went out.
5. Revisit it when the contract or vendor changes
A DoD written for one vendor arrangement doesn't automatically survive the next one. An engagement with no minimum-hour commitment (HighCircl runs its augmented seats that way) lets the size of the nearshore side change from one month to the next without a renegotiation. Every time it does, the review and sign-off answers from step 3 need a fresh look instead of an assumption that last month's names still hold.
Once a Product Backlog Item clears every line on this list, it becomes the queue release management for a blended engineering team works from. A DoD that's easy to fake just moves the same gap one stage downstream, into a release nobody actually vetted.
Common Definition of Done mistakes
A DoD too long to check gets skipped instead of enforced. Twenty items on a checklist means twenty things someone has to verify by hand under sprint pressure, and the items near the bottom stop getting checked first. Keep it short enough that checking it is faster than arguing about it.
A DoD that goes stale is the second failure. A checklist written when the team was three in-house engineers doesn't cover the review and access questions that show up once two nearshore engineers join. Revisit the DoD on a schedule, not only when something breaks because of a gap in it.
The third is a DoD nobody actually enforces at review time. Writing the checklist and never checking it against a real Product Backlog Item before calling it done is worse than not having one, because it creates the appearance of a standard without the substance of one. Whoever signs off, per step 3 above, needs to actually run the list, every time, not just the times something looks off.
FAQ
What is the Definition of Done in Scrum?
A formal description of the state a Product Backlog Item has to reach before it counts as part of an Increment. The Scrum Guide ties it to quality measures required for the product and states that work isn't part of an Increment until it meets that definition.
What is the difference between Definition of Done and Definition of Ready?
Definition of Ready checks whether a story is fit to start; Definition of Done checks whether it's actually finished. DoR isn't a Scrum Guide term at all, while Definition of Done is defined directly in the guide's text.
Who creates the Definition of Done?
The organization first, if it has one. The Scrum Guide requires every Scrum Team to follow an organizational DoD standard as a minimum where one exists. Without one, the Scrum Team writes its own, appropriate to its product.
Does the Definition of Done change when part of the team is nearshore or outsourced?
The quality bar itself shouldn't change, but the checklist usually needs new lines that a single-org team never had to write: who reviews code across the split, who has the access to deploy, and who signs off before a Product Backlog Item counts as done.
What happens if a task doesn't meet the Definition of Done?
It isn't part of the Increment. The Scrum Guide is explicit that work cannot be considered part of an Increment unless it meets the Definition of Done, regardless of how close it looks to finished.