Definition of Ready vs Done (DoR & DoD): The Quality Gates Every Agile Team Needs
Summary
- The “Ready” Rule: If you have to ask “what does this mean?” in Planning, the item wasn’t ready. Kick it out. No exceptions.
- The “Done” Rule: It’s not done when it compiles. It’s done when I can ship it to a user without embarrassing myself.
- The Pact: These aren’t rules imposed by management. They are agreements between the team and reality.
- The Series Connection: If you’ve done Refinement, Grooming, and Technical Analysis properly, DoR is almost automatic. If you haven’t, no checklist will save you.
You know that feeling when you pull a ticket into a sprint, and three days later someone asks, “Wait, does this include mobile support?” That’s not a requirements problem. That’s a discipline problem. We treat “Ready” and “Done” like bureaucratic checkboxes. They aren’t. They are the only thing standing between you and a chaotic, never-ending sprint. And here’s the thing most people miss: DoR and DoD don’t exist in isolation. They are the natural output of every ceremony we’ve covered in this series—from Refinement’s filtering to Technical Analysis’s decomposition. If those earlier phases work, these definitions almost write themselves.
Part 10 of the Agile Series — The Complete Cheat Sheet.
How the Entire Series Feeds Into DoR & DoD
Before diving into the checklists, let’s see how each phase of the Agile cycle connects to these definitions. This is the big picture most teams miss:
Refinement (Series #2) → DoR
Back-of-the-envelope ROI calculation already happened. The idea survived the filter. If it didn’t pass Refinement, it shouldn’t even exist in the backlog, let alone be “Ready.”
Grooming (Series #3) → DoR
The PO sold the vision. The team understands what is requested and why it’s valuable. Context has been transferred. If the team walked out of Grooming confused, the item is not Ready.
Technical Analysis (Series #4) → DoR
The team decomposed the work into technical tasks. API contracts are defined. QA wrote test cases before coding. Risks were surfaced in the pre-mortem. If Technical Analysis was done properly, the item is Ready by definition.
INVEST (Series #9) → DoR
The story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. If it fails any INVEST criterion, it’s not Ready.
Daily Standup (Series #6) → DoD
The burndown chart only drops when an item is marked “Done”—not when code is working locally. DoD defines when that chart moves.
Sprint Review (Series #8) → DoD
Only items that meet DoD are demonstrated to stakeholders. If it doesn’t pass DoD, it doesn’t go into the Review. Period.
Retrospective (Series #7) → DoR & DoD Evolution
Definitions aren’t set in stone. The Retro is where you review and evolve them based on what you learned.
Definition of Ready (DoR)
The Definition of Ready is a checklist of conditions that must be met before a backlog item can enter a sprint.
Why DoR Exists: Stop Failing Before You Start
Here’s what happens without a DoR: every sprint is a lottery. One sprint goes fine because the PO happened to describe the story well. Next sprint, a different PO throws in a half-baked idea and the team burns three days just figuring out what was actually asked. Sound familiar?
The problem isn’t bad luck. The problem is having no standard for preparation. Without a DoR, you’re relying on individual effort and hope. Some sprints work, some don’t, and nobody can explain why. DoR removes the randomness. It says: “This is the bar. If the work doesn’t meet it, it doesn’t enter the sprint. Period.” When you have a standard, promises become keepable. When you don’t, every sprint is a different flavor of surprise. DoR isn’t about bureaucracy—it’s about not setting your team up to fail before the sprint even starts.
Example DoR
Clear User Story (INVEST-Compliant)
The story follows the “As a… I want… So that…” format with clear value. It passes all six INVEST criteria—especially Small and Testable.
Acceptance Criteria Defined
Specific, testable criteria that define success. Not vague wishes like “it should work well.”
Technical Analysis Complete
The team has decomposed the work. DB changes, API contracts, and refactoring needs are documented. Grey areas have been eliminated.
QA Test Cases Written
QA doesn’t wait for code to be written. Test cases exist before sprint starts—developers know exactly what will be tested.
Dependencies Identified
External dependencies (APIs, other teams, third parties) are known, scheduled, and have a mitigation plan.
UX/Design Ready
If applicable, mockups or designs are approved and available. No “we’ll figure out the UI later.”
Real-World Example: Product Listing Page
Remember the product listing page from the INVEST article? Let’s apply DoR to it. If someone throws “Implement product listing with filters” into the sprint, ask: Is it Ready?
Definition of Done (DoD)
The Definition of Done is a checklist of quality criteria that must be met before an item is considered complete. This is the gate that determines whether something can be shown in the Sprint Review.
Why DoD Exists: The Team Charter
Let me describe a scene you’ve definitely witnessed: a developer moves a ticket to “Done” and says, “I wrote the code, it’s deployed.” Then QA finds three bugs. Then someone realizes there are no logs. Then the feature breaks in production at midnight and nobody knows because there are no alerts. “But I wrote the code!” Yes. And that’s exactly the problem.
“I wrote my part” is an individual mindset. DoD is a team mindset. A team doesn’t ship code—a team ships a working, tested, monitored, rollback-ready product increment. If the increment can’t be delivered according to DoD, the whole team owns that failure—not just the developer, not just QA, not just DevOps. Everyone.
Think of DoD as your team’s constitution. Not rules imposed from above, but an agreement the team makes with itself: “This is what ‘finished’ means to us. We don’t cut corners. We don’t declare victory early. If it doesn’t meet this bar, it’s not done—no matter who wrote the code.” When a team truly internalizes this, “I wrote the code” stops being a finish line and starts being a checkpoint. The finish line is: “We can ship this to users right now, and sleep well tonight.”
Example DoD
Code Complete
All implementation is finished and follows team coding standards.
Tests Passing
Unit tests, integration tests, and any required E2E tests are green. This isn’t negotiable—as we covered in Technical Analysis, QA defined the target before coding started.
Code Reviewed
At least one peer review completed and feedback addressed. No rubber-stamp approvals.
Documentation Updated
API docs, README, or user-facing docs updated if applicable.
Observability in Place
Logging, metrics, and alerts configured for production monitoring. If it breaks at 3 AM, someone knows.
Deployed to Staging
Successfully deployed and verified in a staging environment. Not “it compiles.”
Rollout Plan Defined
Feature toggles, gradual rollout, or rollback strategy documented. As discussed in the INVEST article: going live (deploying) doesn’t mean opening to users (releasing). Feature Toggle is part of your Definition of Done.
DoR vs DoD: Side by Side
Before Sprint
Gate for items entering the sprint. Protects the team from ambiguous work. If Refinement, Grooming, and Technical Analysis did their job, this gate is easy.
End of Sprint
Gate for items leaving the sprint. Ensures consistent quality. This determines what gets shown in Sprint Review and what moves the burndown chart.
| Aspect | Definition of Ready | Definition of Done |
|---|---|---|
| When checked | Before Planning | Before marking complete |
| Who owns | Product Owner + Team | Development Team |
| Purpose | Prevent unclear work | Ensure quality |
| Failure mode | Surprises mid-sprint | ”Done” that isn’t releasable |
| Fed by | Refinement, Grooming, Tech Analysis, INVEST | Code standards, testing, CI/CD, feature toggles |
Tailoring to Team Size
Small Team
Lightweight DoR/DoD. Trust and verbal agreements work. Keep it to 3-4 items each. Overhead kills small teams.
Standard Team
Explicit checklists. Document and review quarterly in Retros. Balance rigor with speed. This is the sweet spot for most teams.
Large Team
Formal DoR/DoD. Automated checks where possible (CI/CD gates, linter rules, coverage thresholds). Consider splitting the team if this list grows beyond 10 items.
Common Mistakes
Too Many Criteria
20-item checklists become checkbox theater. Keep it to 5-7 essential items. If everything is important, nothing is.
Never Updated
DoR/DoD should evolve. Review and adjust based on Retro feedback—this is exactly what Series #7 (Retrospective) is for.
Ignored Under Pressure
“We’ll skip tests this sprint.” This defeats the purpose. Definitions are non-negotiable. The moment you bend them for a deadline, they become meaningless.
Invisible to Stakeholders
If stakeholders don’t know the DoD, they’ll push for “done” that isn’t shippable. Share the DoD in Sprint Review so everyone knows what “done” means.
Making It Stick
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released.
The Bottom Line
DoR and DoD are not standalone documents you write once and forget. They are the natural output of a well-functioning Agile cycle. If Refinement filters ideas properly, Grooming transfers context, Technical Analysis eliminates grey areas, and INVEST ensures story quality—DoR writes itself. If your coding standards, testing culture, CI/CD pipeline, and feature toggle strategy are solid—DoD writes itself. Start simple, enforce consistently, and evolve in Retros. When done right, these definitions become invisible—because quality becomes the default.