Principles of Product Management: Definition of Ready, Definition of Done (DoR / DoD)

Definition of Ready, Definition of Done (DoR / DoD)

Definition of Ready (DoR) & Definition of Done (DoD) – Study Guide

What This Is

Definition of Ready (DoR) is a checklist that ensures a work item (e.g., user story, feature, or task) is fully prepared before the team starts building it. Definition of Done (DoD) is a shared agreement on what must be true for a work item to be considered complete. These concepts matter because they reduce ambiguity, prevent rework, and align teams on quality standards—critical for shipping products efficiently. Example: A fintech startup launching a "One-Click Recurring Payments" feature might use DoR to confirm the user flow is validated with 5+ customers and DoD to ensure the feature is tested for fraud risks, meets accessibility standards, and has analytics tracking in place.

Key Terms & Frameworks

• Definition of Ready (DoR): A set of criteria that must be met before a work item enters development (e.g., "User story is written in Gherkin format," "Acceptance criteria are defined," "Dependencies are resolved"). Ensures the team isn’t wasting time on poorly scoped work.

• Definition of Done (DoD): A checklist of conditions that must be satisfied for a work item to be considered "shipped" (e.g., "Code reviewed," "Unit tests pass," "Documentation updated"). Prevents technical debt and ensures consistency.

• INVEST (User Stories): A framework for writing good user stories:

• Independent (can be developed separately),
• Negotiable (not a contract),
• Valuable (delivers user/business value),
• Estimable (team can size it),
• Small (fits in a sprint),

• Testable (clear acceptance criteria).

• 3 Amigos (Collaboration): A meeting between Product (PM), Development (Engineering), and Quality (QA) to align on DoR/DoD before work begins. Reduces miscommunication.

• Acceptance Criteria (AC): Specific, testable conditions that must be met for a work item to be "done." Written in Given-When-Then format (e.g., "Given a user has saved payment details, when they click ‘Pay,’ then the transaction processes without re-entering credentials").

• Technical Debt Quadrant (Martin Fowler): A 2x2 matrix to classify debt:

• Reckless/Deliberate (bad, e.g., skipping tests to meet a deadline),
• Prudent/Deliberate (acceptable, e.g., prototyping without tests),
• Reckless/Inadvertent (bad, e.g., poor architecture due to inexperience),

• Prudent/Inadvertent (unavoidable, e.g., legacy system constraints).

• DoR vs. DoD:

• DoR = "Is this ready to start?" (Inputs)

• DoD = "Is this ready to ship?" (Outputs) Mistake: Treating DoR as optional or DoD as static (it evolves with team maturity).

• Continuous Discovery (Teresa Torres): Ongoing user research to validate assumptions before adding them to DoR (e.g., "We assume users want dark mode—let’s interview 10 users first").

• Definition of Ready Formula (Simplified): DoR = (User Problem Validated) + (Acceptance Criteria Defined) + (Dependencies Resolved) + (Team Alignment) Example: For a "Passwordless Login" feature, DoR might include:

• User interviews confirm 70% of users struggle with passwords.
• AC includes "Works with SMS and email OTP."

• Engineering confirms no backend blockers.

• Definition of Done Formula (Simplified): DoD = (Code Complete) + (Tested) + (Documented) + (Monitored) + (User Feedback Collected) Example: For a "Checkout Abandonment Email" feature, DoD might include:

• A/B test results show a 5% lift in conversions.
• Analytics track open/click rates.
• Support team is trained on FAQs.

Step-by-Step / Process Flow

1. Align on DoR/DoD Early

2. At the start of a project (or sprint planning), facilitate a 3 Amigos session to draft DoR/DoD. Use a template like: ``` DoR:

   • [ ] User story follows INVEST.
   • [ ] Acceptance criteria are written in Given-When-Then.
   • [ ] Dependencies (e.g., API, design) are resolved. DoD:
   • [ ] Code reviewed and merged.
   • [ ] Unit/integration tests pass.
   • [ ] Feature flagged for gradual rollout.
   • [ ] Analytics tracking implemented. ```

3. Validate DoR Before Starting Work

4. For each work item, ask: "Does this meet all DoR criteria?" If not, defer it or break it down. Example: If a "Subscription Upsell" story lacks AC, don’t let it into the sprint.

5. Use DoD to Prevent Scope Creep

6. During development, refer to DoD to avoid "just one more thing" requests. Example: If a stakeholder asks for a "social sharing" feature mid-sprint, say: "That’s not in our DoD—let’s add it to the backlog and prioritize it next sprint."

7. Review and Refine DoR/DoD Regularly

8. After each sprint, ask: "What slowed us down? What was missing from DoR/DoD?" Update the checklists. Example: If QA keeps finding edge cases, add "Edge cases documented" to DoR.

9. Tie DoD to Outcomes (Not Outputs)

10. Ensure DoD includes success metrics (e.g., "Feature achieves 10% adoption in 30 days"). Example: For a "Referral Program," DoD might include:
    • Referral CTR > 3%.
    • NPS impact measured post-launch.

Common Mistakes

• Mistake: Treating DoR/DoD as static documents. Correction: Review and update them every sprint. Why? Teams mature, and new risks emerge (e.g., adding "Security review" to DoD after a breach).

• Mistake: Skipping DoR to "save time." Correction: Enforce DoR rigorously. Why? Unready work leads to rework (e.g., a story without AC gets blocked mid-sprint).

• Mistake: Making DoD too rigid (e.g., "Must have 100% test coverage"). Correction: Balance quality with speed. Why? Overly strict DoD can slow down innovation (e.g., allow 80% test coverage for an MVP).

• Mistake: Confusing DoD with "shipped to production." Correction: DoD should include post-launch items (e.g., "Monitoring alerts set up," "User feedback collected"). Why? Shipping-success (e.g., a feature might break in production).

• Mistake: Letting engineers or designers define DoR/DoD alone. Correction: Collaborate across functions (PM, Eng, QA, Design). Why? Misalignment leads to gaps (e.g., missing analytics tracking).

PM Interview / Practical Insights

1. Interviewer Probe: "How do you handle a stakeholder who wants to add a feature mid-sprint?" Answer: "I’d refer to our DoD and DoR. If the feature isn’t in the sprint backlog and doesn’t meet DoR (e.g., no AC, no validation), I’d push back and add it to the next sprint’s backlog. If it’s critical, I’d negotiate scope (e.g., reduce another feature’s scope to accommodate it)." Why? Shows you use DoR/DoD to manage scope and trade-offs.

2. Tricky Distinction: "DoR vs. Acceptance Criteria"

3. DoR = Gatekeeping for starting work (e.g., "User story is sized").

4. AC = Conditions for completing work (e.g., "User can reset password via email"). Trap: Mixing them up (e.g., putting AC in DoR).

5. Stakeholder Trap: "Why can’t we just start building? We’ll figure it out later." Response: "Without DoR, we risk building the wrong thing or getting blocked mid-sprint. For example, if we don’t validate the user problem first, we might waste 2 weeks building a feature no one wants. Let’s spend 1 day aligning on DoR to save 10 days of rework." Why? Positions you as a pragmatic leader.

6. Interviewer Probe: "How do you measure the success of a feature post-launch?" Answer: "I’d include success metrics in the DoD (e.g., ‘Feature achieves 15% adoption in 30 days’). Post-launch, I’d track leading indicators (e.g., click-through rates) and lagging indicators (e.g., retention lift) and compare them to our baseline." Why? Shows you tie DoD to outcomes, not just outputs.

Quick Check Questions

1. Scenario: Your team wants to add a "Dark Mode" feature to the backlog, but user interviews show only 20% of users care about it. The designer insists it’s "table stakes." How do you decide whether to add it to DoR? Answer: "I’d push back on adding it to DoR until we validate demand (e.g., run a survey or A/B test a prototype). If only 20% care, it’s not a priority—we should focus on higher-impact work. DoR exists to prevent wasted effort on unvalidated ideas." Explanation: DoR should include evidence of user/business value.

2. Scenario: Your engineering team says a feature is "done" (code merged, tests pass), but the DoD includes "Analytics tracking implemented." The engineer argues, "We can add tracking later." What do you do? Answer: "I’d block the release until tracking is added. DoD is a contract—if we skip it, we won’t know if the feature is working post-launch. I’d negotiate scope (e.g., ‘Let’s ship a minimal version with tracking now and iterate later’)." Explanation: DoD is non-negotiable; skipping it creates blind spots.

3. Scenario: A stakeholder asks, "Why do we need DoR? Can’t we just start building and refine as we go?" How do you respond? Answer: "DoR prevents rework and misalignment. For example, if we start building a feature without clear AC, we might realize mid-sprint that it doesn’t solve the user’s problem. DoR ensures we validate assumptions upfront (e.g., ‘Does this user story align with our OKRs?’)." Explanation: DoR is a risk-mitigation tool, not bureaucracy.

Last-Minute Cram Sheet

1. DoR = "Is this ready to start?" (Inputs: validation, AC, dependencies).
2. DoD = "Is this ready to ship?" (Outputs: code, tests, docs, monitoring).
3. INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable (for user stories).
4. 3 Amigos = PM + Eng + QA alignment on DoR/DoD.
5. Acceptance Criteria = Given-When-Then format (e.g., "Given X, when Y, then Z").
6. DoR Formula: (User Problem Validated) + (AC Defined) + (Dependencies Resolved) + (Team Alignment).
7. DoD Formula: (Code Complete) + (Tested) + (Documented) + (Monitored) + (User Feedback).
8. DoR-AC: DoR is about starting work; AC is about completing it.
9. Update DoR/DoD every sprint—they’re living documents.
10. Tie DoD to outcomes (e.g., "Feature achieves X% adoption in Y days").