9.2 Acceptance Criteria vs. Definition of Done (DoD) vs. Definition of Ready (DoR)

9.2 Acceptance Criteria vs. Definition of Done (DoD) vs. Definition of Ready (DoR)

Quick Answer: The Triple Quality Gate framework governs agile software delivery through three complementary checkpoints: Definition of Ready (DoR) determines if a story is mature enough to be pulled into a sprint; Acceptance Criteria (AC) defines the unique functional and business conditions required for the Product Owner to accept that specific story; and Definition of Done (DoD) establishes the universal, non-negotiable technical, security, and release engineering standards that every story must satisfy before being deployed to production.

In fast-paced Salesforce agile projects, teams frequently conflate the concepts of Acceptance Criteria, Definition of Done, and Definition of Ready. When these quality gates are blurred, project execution breaks down: developers pull half-baked requirements into active sprints, stories pass business testing but crash production deployments due to low test coverage, and teams argue during sprint reviews over whether a feature is truly complete.

For the Salesforce Certified Business Analyst, understanding the distinct operational boundary, governance model, and lifecycle timing of each gate is critical for maintaining delivery velocity, preventing technical debt, and passing scenario-based exam questions.

---

The Triple Quality Gate Framework in Salesforce Agile Delivery

Think of agile delivery as an industrial assembly line protected by three successive quality inspection checkpoints. Each checkpoint asks a fundamentally different question, serves a specific stakeholder group, and evaluates distinct artifacts.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE TRIPLE QUALITY GATE LIFECYCLE                       │
├─────────────────────────────────────────────────────────────────────────────┤
│  GATE 1: Definition of Ready (DoR)                                          │
│  "Is this backlog item mature, understood, and unblocked for development?"   │
│  --> Applied during Backlog Refinement & Sprint Planning                    │
│                                     │                                       │
│                                     ▼                                       │
│  GATE 2: Acceptance Criteria (AC)                                           │
│  "Does this specific build fulfill the unique business requirements?"        │
│  --> Applied during Development, QA Functional Testing & Sprint Review      │
│                                     │                                       │
│                                     ▼                                       │
│  GATE 3: Definition of Done (DoD)                                           │
│  "Does this increment satisfy universal architectural & release standards?" │
│  --> Applied before Closing Story & Deploying to Production                 │
└─────────────────────────────────────────────────────────────────────────────┘

Why Teams Need All Three Gates

• A story can meet AC but fail DoD: A developer builds a custom Lightning Web Component that executes the exact business calculation required by the Product Owner (passes AC). However, the developer wrote zero Apex unit tests, omitted error handling, and hardcoded record IDs in JavaScript (violates DoD). The story cannot be released.
• A story can meet DoD but fail AC: An engineering team writes flawless, bulkified Apex code with 100% test coverage, comprehensive error logging, and full CI/CD deployment validation (passes DoD). However, the code calculates sales tax using gross margin rather than net invoiced amount (fails AC). The software is technically pristine but commercially incorrect.
• A story bypassing DoR creates chaos: If the team pulls a user story into sprint execution without finalized wireframes, validated API endpoint documentation, or confirmed acceptance criteria, developers stall mid-sprint, asking basic questions while sprint velocity plummets.

---

Gate 1: Definition of Ready (DoR) — The Sprint Intake Gatekeeper

The Definition of Ready (DoR) is a formal working agreement between the Scrum team and the Product Owner. It establishes the minimum threshold of clarity, completeness, and independence that a user story must achieve before the development team commits to building it in an upcoming sprint.

Core Characteristics of DoR

• Temporal Phase: Evaluated during Backlog Refinement sessions and confirmed during Sprint Planning.
• Scope of Application: Team-wide standard applied to every candidate backlog item before sprint intake.
• Primary Purpose: Prevents team churn, scope instability, and mid-sprint blockers by filtering out immature requirements.
• Governance: Owned collaboratively by the Scrum Master, Technical Lead, BA, and Product Owner.

Standard Salesforce Definition of Ready Checklist

An enterprise Salesforce agile team typically requires that every story satisfy the following DoR conditions:

1. Structured Narrative: The story follows standard role-action-benefit syntax (As a... I want... So that...) with a clearly identified business persona.
2. Drafted Acceptance Criteria: Comprehensive AC is documented, detailing both happy path and critical negative/validation conditions.
3. INVEST Framework Alignment: The story is Independent, Negotiable, Valuable, Estimable, Small (can be completed within a single sprint), and Testable.
4. Agile Estimation Sized: The story has been sized in story points (e.g., via Planning Poker) by the development team and does not exceed the team's maximum story size threshold (typically 8 story points).
5. Dependencies Resolved or Mapped: External system API contracts (e.g., SAP, MuleSoft, Workday), schema changes, or third-party AppExchange dependencies are documented and accessible in sandbox environments.
6. UX & UI Assets Attached: For front-end Lightning Experience or Experience Cloud changes, wireframes, page mockups, or field layout specifications are attached to the work item.
7. Test Data Identified: Verification data (e.g., representative Billing Account records or sanitized test data) exists in developer and QA scratch orgs or sandboxes.

---

Gate 2: Acceptance Criteria (AC) — The Story-Specific Business Gate

Acceptance Criteria (AC) represent the unique, story-specific functional and operational criteria that define success for that individual piece of software.

Core Characteristics of AC

• Temporal Phase: Authored during refinement, referenced continuously during development, and verified during QA testing and Product Owner sprint review demonstrations.
• Scope of Application: Completely unique to each individual user story. No two stories share the exact same AC.
• Primary Purpose: Guarantees that the software increment delivers the precise business utility, data behavior, and workflow logic intended by stakeholders.
• Governance: Elicited and authored by the Salesforce BA, verified by QA, and formally signed off by the Product Owner.

Practical Salesforce AC Examples

• "When a Sales Rep selects 'Closed Lost', the 'Loss Reason' picklist becomes mandatory and displays six specific loss categories."
• "High-severity Service Cloud cases automatically reassign to the Tier-3 Escalation Queue within 60 seconds if unassigned."
• "The 'Tax Exemption Certificate' field is visible exclusively to the Billing Operations profile."

---

Gate 3: Definition of Done (DoD) — The Universal Release Gate

The Definition of Done (DoD) is a comprehensive, non-negotiable checklist of technical, security, operational, and architectural standards that every user story must satisfy before it can be classified as complete and eligible for production release.

Core Characteristics of DoD

• Temporal Phase: Enforced at the end of development, during peer review, CI/CD automated pipeline builds, regression testing, and release packaging.
• Scope of Application: Universal and static across the entire product backlog. Every story—regardless of whether it builds a simple validation rule or a complex integration—must satisfy the applicable technical checklist items.
• Primary Purpose: Eliminates technical debt, guarantees platform stability, enforces architectural and regulatory compliance, and ensures clean release engineering.
• Governance: Formulated and owned by the entire delivery team (Developers, Architects, QA Engineers, DevOps, and Scrum Master).

Enterprise Salesforce Definition of Done Checklist

A robust enterprise Salesforce Definition of Done encompasses technical, operational, and enablement criteria:

• Technical Quality & Architecture Standards:
  • Declarative-First Policy: Verified that native configuration (Flow, Validation Rules, Approvals) was prioritized over custom code.
  • Apex Code Coverage: All newly authored Apex classes and triggers maintain >= 75% test coverage (team target: >= 85%) with positive, negative, and bulk (200 records) test assertions without using @SeeAllData=true.
  • Static Code Analysis: Clean scan via PMD, SonarQube, or Salesforce Code Analyzer with zero Critical or Blocker violations.
  • Governor Limits & Bulkification: Custom automation tested to ensure no SOQL queries, SOSL queries, or DML operations execute inside iterative loops.
  • Peer Review: Pull request reviewed and approved by at least one Senior Salesforce Developer or Technical Architect.
• Testing & Release Verification:
  • Automated Regression Suite: Core regression test suite passes in the Integration Sandbox (UAT org) with zero regressions.
  • Cross-Browser & Device Verification: Lightning components verified across Chrome, Safari, Edge, and Salesforce Mobile App.
  • Accessibility (WCAG): Lightning Web Components meet WCAG 2.1 AA contrast and screen-reader accessibility standards.
• Governance & Operational Enablement:
  • Metadata Dictionary Updated: All new custom fields, objects, and permission sets documented in the enterprise data dictionary.
  • Deployment Script Validated: Changes tracked in version control (Git) with validated CI/CD deployment package.
  • Release Notes & Job Aids: End-user release documentation and job aids delivered to the corporate enablement team.

---

Comprehensive Diagnostic Comparison Matrix

The following matrix summarizes the fundamental distinctions that frequently appear on the Salesforce Certified Business Analyst examination:

---

Diagnostic Scenarios: Tracing Defects & Blockers to the Correct Quality Gate

A signature capability tested on the exam is diagnosing the root cause of an agile breakdown. When something goes wrong in a project, a skilled BA immediately pinpoints which quality gate failed.

Diagnostic Scenario 1: The Mid-Sprint Integration Blocker

• Incident: In Sprint 14, an agile team commits to a user story requiring real-time tax calculation via an external Vertex API callout. Two days into the sprint, the Salesforce developer discovers that the Vertex test endpoint URL has not been provisioned, API credentials do not exist in the sandbox, and the JSON payload schema is undefined. The story is blocked and fails to deliver in the sprint.
• Root Cause Analysis: Failure of Definition of Ready (DoR).
• BA Remediation: The story should never have been pulled into the active sprint. The DoR should mandate that external technical dependencies, API endpoint contracts, and sandbox credentials are fully operational before sprint planning.

Diagnostic Scenario 2: The Rejected Lead Status Flow

• Incident: During the sprint demonstration, a developer presents a newly built Record-Triggered Flow that automates Lead qualification. The Sales Operations Manager notes that while the Flow updates the status to 'Qualified', it fails to enforce that the 'Lead Qualification Source' picklist is populated, allowing leads to enter the pipeline without marketing attribution.
• Root Cause Analysis: Failure of Acceptance Criteria (AC).
• BA Remediation: The story's acceptance criteria either omitted the mandatory validation rule for 'Lead Qualification Source' or the developer and QA tester failed to execute the negative test scenario. The story is returned to the team for functional remediation.

Diagnostic Scenario 3: The Deployment Pipeline Collapse

• Incident: A user story delivering a custom Case Escalation Lightning Web Component passes all functional acceptance criteria in the developer sandbox. The Product Owner excitedly signs off during the sprint demo. However, when the CI/CD pipeline attempts to deploy the branch to the Staging environment, the automated deployment aborts because overall Apex code coverage drops to 71% and three existing unit tests fail.
• Root Cause Analysis: Failure of Definition of Done (DoD).
• BA Remediation: The team claimed the story was complete based solely on functional AC while ignoring the universal Definition of Done. A story can never be marked 'Done' until universal technical gates—including the mandatory >= 75% Apex code coverage rule and regression pass criteria—are fulfilled.

---

Common Exam Traps & Anti-Patterns

• Trap 1: Believing DoD is Customized Per User Story: Exam questions often feature distractors suggesting that the development team should write a customized Definition of Done for each individual story. This is false. Acceptance Criteria are story-specific; the Definition of Done is universal to the entire project or product.
• Trap 2: Relaxing DoR to Fill Sprint Capacity: When a team runs out of refined stories during sprint planning, a common anti-pattern is pulling in unrefined, unestimated stories just to 'fill the sprint velocity'. On the exam, the correct BA action is to protect the team by enforcing the DoR, even if it means refining items mid-cycle or pulling from a prioritized buffer of technical debt stories.
• Trap 3: Treating DoD as a Post-Sprint or Pre-Release Phase: In immature organizations, teams treat DoD activities (like regression testing, security scanning, or user documentation) as a separate 'hardening sprint' that takes place weeks after development. Modern Salesforce agile practices enforce DoD compliance within each single sprint increment.