Definition of Ready and Done: Getting Agreement Right
Most teams treat Definition of Ready (DoR) as a checklist of technical boxes to tick. That’s not wrong—but it’s incomplete. The real value comes not from checking items, but from the conversation that creates them.
If your team’s DoR is just a list, you’re already at risk. You’ve lost the purpose. The moment you stop discussing *why* a story is ready, you’ve traded clarity for compliance.
As someone who’s guided dozens of teams through sprint chaos, I’ve seen the same pattern: stories arrive in sprint planning with missing acceptance criteria, unclear user roles, or untestable outcomes. The team tries to fix it mid-sprint. That’s not agility. That’s firefighting.
This chapter is about building shared ownership. You’re not here to write a perfect DoR. You’re here to build a shared understanding that prevents rework, reduces bottlenecks, and keeps delivery predictable. By the end, you’ll know how to create a living DoR and DoD, one that evolves with your team.
Why Definition of Ready Matters More Than You Think
DoR isn’t about control. It’s about predictability. It’s the moment when a story transitions from “idea” to “work.” Without agreement, that transition becomes a negotiation every sprint.
Teams that skip DoR end up with stories that are too big, unclear, or untestable. The result? Developers guess. QA waits. Product owners get frustrated.
DoR is where planning meets execution. It’s the *minimum bar* for a story to be picked up. But it’s also the threshold for collaboration. When everyone agrees on readiness, you’re not just checking boxes—you’re aligning minds.
Here’s what I’ve learned: a DoR that’s not co-created will fail. It must be built by the team—developers, testers, product owner, even UX. Not because it’s “Agile,” but because it’s the only way to get true clarity.
What Happens When DoR Is Missing?
- Stories are pulled into sprint without proper acceptance criteria.
- Developers waste time asking “What does this mean?”
- Testers can’t start until the story is “done.”
- Backlog becomes a dumping ground for half-formed ideas.
These are symptoms of a broken DoR. The fix isn’t more documentation—it’s more conversation.
Building a Living Definition of Ready
Start with the basics. What must be true for a story to be considered “ready”?
Here’s a real-world DoR checklist that evolved from working with a fintech team:
| Agreement Criterion | Why It Matters |
|---|---|
| User role is defined (e.g., “As a verified customer”) | Prevents ambiguity in value and intent |
| Clear, testable acceptance criteria (3+) | Ensures the story is verifiable |
| Story is sized under 5 points | Implies it fits in a sprint |
| Dependencies are identified and resolved | Prevents blockers mid-sprint |
| Design or UX mockup attached (if needed) | Reduces guesswork during dev |
This isn’t a one-time setup. It’s a living agreement. It changes as your team learns.
For example, one team found they kept picking up stories with missing acceptance criteria. They added: “All stories must have at least one acceptance test written in Given-When-Then format.” That simple rule cut rework by 40% in two sprints.
Practical Tips for Co-Creating DoR
- Run a “DoR workshop” before sprint 1. Use real stories from backlog.
- Ask: “What could go wrong if we started this now?”
- Start small. 3–5 criteria max. Overloading kills adoption.
- Review DoR every sprint. Ask: “Did anything break?”
- Link DoR to estimation. If a story can’t be estimated, it’s not ready.
DoR isn’t a gate. It’s a signal. When a story passes DoR, it’s not “approved.” It’s “understood.” That distinction matters.
Definition of Done: The Real Measure of Completion
DoD is where DoR ends and delivery begins. It’s the final quality checkpoint. But too many teams treat it as a formality.
I’ve seen teams ship features that failed in production—not because of bugs, but because they missed basic compliance: no deployment script, no security review, no documentation.
DoD isn’t just “code complete.” It’s *business-ready*. It’s about trust. When a story is “Done,” it should be deployable. Testable. Understandable.
Creating a Meaningful Definition of Done Checklist
Here’s a DoD checklist that works across multiple teams:
- Code has passed peer review and is merged to main.
- All acceptance tests pass (automated and manual).
- No known security vulnerabilities (SAST/DAST scan).
- Documentation updated (user guide, API, release notes).
- Deployed to staging and verified.
- Backlog item is closed and linked to test results.
This isn’t a checklist for show. It’s a contract. Every time a story passes DoD, the team builds confidence.
One team I worked with added a final step: “A user can verify the feature in under 2 minutes.” That simple rule forced them to simplify their UX. The result? 60% drop in support tickets.
DoR vs. DoD: Key Differences
| Aspect | Definition of Ready (DoR) | Definition of Done (DoD) |
|---|---|---|
| Timing | Before sprint planning | After development and testing |
| Focus | Is this story ready to be worked on? | Is this work truly complete? |
| Who owns it? | Product Owner + Team | Whole Team |
| Flexibility | Can vary per story | Consistent for all stories |
DoR is about *preparation*. DoD is about *proof*. One prepares. The other certifies.
Real-World Example: How a Team Fixed Their DoR
A healthcare tech team was missing 40% of their sprint goals. Stories were rejected in sprint planning for being too vague or too big.
They ran a two-hour DoR workshop. They took five stories from their backlog and asked: “What’s missing?”
They found:
- Three stories lacked user role.
- Two had no acceptance criteria.
- One used technical jargon like “integrate with API.”
They created a DoR with three rules:
- Must start with “As a [role], I want…”
- Must have two testable acceptance criteria
- Must be estimable and split from an epic
After two sprints, their sprint success rate jumped from 60% to 85%. Not because they worked faster—but because they worked smarter.
Frequently Asked Questions
What’s the difference between Definition of Ready and Definition of Done?
DoR ensures a story is *ready to be worked on*. DoD ensures it’s *actually done*. DoR is about preparation. DoD is about verification.
How often should we review our Definition of Ready?
Review it at least every sprint. If a story keeps failing DoR, dig deeper. Is the team misunderstanding? Is the backlog too vague? Fix the root cause, not the symptom.
Can DoR vary between teams in the same organization?
Yes—but only if it makes sense. In a feature team model, each team can define their own DoR. But in a component team model, shared DoR is essential. The key is alignment, not uniformity.
What if the Product Owner doesn’t agree with the DoR?
DoR isn’t a law. It’s a team agreement. If the PO disagrees, the team must discuss why. The goal isn’t consensus—it’s clarity. If the story isn’t clear, it shouldn’t be in the sprint.
Is DoD the same for every team?
Not necessarily. Some teams need extra compliance steps (like audit logs or legal review). But the core—code, tests, docs, deployment—should be consistent across teams.
How do I handle stories that are too big for DoR?
Use story splitting techniques. If a story can’t be split into small, testable pieces, it’s likely an epic. Split it using the “who, what, why” pattern. Then re-evaluate DoR.
