Definition of Done and Definition of Ready Aren't Checklists
Team Atlas had the best Definition of Ready I'd ever seen. Six items, reviewed quarterly, printed on a poster in the team room. Their Definition of Done checklist had test coverage thresholds, a security review step, and a documentation checkbox nobody skipped. On paper, this was a team that had solved the problem.
They still fought about scope every single sprint.
Not because the checklists were wrong. Because nobody in the room actually believed in them anymore. The PO ticked the DoR boxes to get a story into planning. The team ticked the DoD boxes to close a ticket. Everyone was following the rules. Nobody was making a commitment.
That's the part the DoD/DoR debate keeps missing.
Quick Version, For Anyone Who's Never Needed One
If you've never had to think about this: Definition of Ready (DoR) is the answer to "when is a story allowed to start?" Definition of Done (DoD) is the answer to "when is it actually finished?" Scrum.org draws the same line: DoD is the shared understanding of what "finished" means for the increment. Boost.co.nz puts the distinction even more plainly: DoR covers what comes into the sprint, DoD covers what comes out. That's the classic Definition of Done vs. Definition of Ready split, and it's exactly right, as far as it goes.
That's it. I'll give you a handful of examples below, just enough to place it, not a full checklist. You can find twenty different definition of done examples in five minutes, and that's part of the problem this article is about.
Two Camps, One Blind Spot
There's a real fight in the Scrum world about whether DoR should exist at all. Mike Cohn, of Mountain Goat Software, put the sharpest image on it: DoR as a bouncer standing at the door of the sprint, letting in only the stories that look right. His point isn't just a metaphor. Parabol's catalog of Scrum anti-patterns names this exact failure directly: over-reliance on the definition of ready, with real consequences attached. Not just annoyance, but delayed critical work and, in some cases, measurable financial loss.
The other side pushes back hard, and not quietly. A widely discussed LinkedIn post, one that pulled in dozens of replies from practitioners, argued that calling DoR an anti-pattern misreads the concept entirely. Having a shared checklist for "is this story ready to work on" isn't a violation of anything. It's a recipe. A shopping list. You don't call a grocery list an attack on your ability to cook dinner.
Both camps agree on one thing, even mid-fight: a DoR or DoD that turns into a rigid gate is bad. Nobody defends the version that blocks work indefinitely because a checkbox is unticked. The fight isn't really "should we have one." It's "how do we stop it from becoming exactly what everyone already agrees is bad."
Team Atlas never had that fight. Their DoR had been signed off years ago and never revisited. Nobody in the room was arguing about it anymore, which meant, by the logic both camps actually share, it had already gone bad. Nobody noticed, because the poster on the wall still looked complete. That's the quiet version of Parabol's anti-pattern: a slow drift into a form nobody questions anymore, with no dramatic blockage at any point.
That's a narrower argument than it sounds. And it's the wrong argument entirely.
What "Commitment" Means That a Checklist Can't
Here's the reframe: DoD and DoR were never meant to be documents. They're commitments, a promise between the people building something about what "ready" and "done" actually mean between them. ServiceNow's engineering community put this well: neither gate is a hand-off point between roles. Both stay a team effort, defined and used together, and revisited the moment either side stops making sense.
A checklist can be signed by one person and enforced on everyone else. A commitment can't. The difference shows up the moment something's ambiguous. On a checklist, ambiguity gets resolved by finding the closest matching box and ticking it. In a commitment, ambiguity gets resolved by going back to the people who made the agreement and asking what they actually meant.
Team Atlas had the checklist. They'd lost the second part years ago. The PO wasn't negotiating readiness with the team, she was filling out a form to get past a gate. The developers weren't agreeing on "done," they were checking boxes fast enough to close the ticket before standup. Nobody was in the room anymore. Just the form.
That's the actual failure mode, and it has nothing to do with whether the checklist itself is good.
Why Checklists Still Aren't the Problem
I want to be clear about something, because it's tempting to read this as "throw out your DoD and DoR." Don't.
For a small team that's worked together for years, an unwritten DoR can genuinely work. Everyone already knows what "ready" means, because they've built the shared understanding through repetition, not documentation. Boost.co.nz makes the same case from the other direction: formalize it only once specific, recurring gaps in your stories are actually stopping the team from finishing work, not by default, just in case. That's earned trust, and it's real.
But most teams aren't that team. New members join. Product changes hands. A team that's growing, distributed, or operating in a regulated space doesn't have the luxury of "we all just know." Scrum Alliance frames a written DoR as training wheels for exactly this situation, useful for teams that haven't yet learned to write good backlog items on instinct. For them, a written DoD/DoR isn't something to be embarrassed about. It's the fastest way to build the same shared understanding that a tight-knit team gets for free through years of working side by side.
Team Atlas, ironically, had outgrown their own training wheels without noticing. They didn't need a better checklist. They needed to admit the checklist had stopped doing the one job training wheels are supposed to do: teach the team to ride without them, or get thrown out once it can. Boost.co.nz's own logic points the same way in reverse. If the specific gap the DoR was built to close hasn't come up in months, that's worth naming out loud too, not just quietly kept "just in case."
So the checklist isn't the enemy. The checklist is a tool for building a commitment that doesn't exist yet. The problem starts the moment the tool outlives the thing it was built for, when the team stops updating it and stops arguing about it, and starts treating it as a form to clear instead of a living agreement.
The Question That Actually Matters
Don't ask your team "do we have a DoD and DoR?" Almost everyone does, at this point. That question tells you nothing.
Ask this instead: "When did we last question it together?"
If the honest answer is "never," if nobody can remember the last time the team sat down and argued about whether the DoR still made sense, it's already calcified into paperwork. No matter how complete the checklist looks on the wall. And I'd bet more than a few of those checkboxes get ticked just to be ticked, not because anyone actually checked.
The document was never the point. The argument that produced it was.
Shift-Left with BDD: The Full Journey
Curious what a real DoD and DoR looks like in practice? This course walks a whole team through building that commitment, from first conversation to production.
View the course