Definition of Done

Quality gate criteria that a user story must meet before it can be marked as complete on a Salesforce project

Category: Agile
Tags: agile definition-of-done salesforce quality code-review

Author: callinj
Name: Joe Callin
Title: Sr. Salesforce Developer
Email: joe@jcallin.dev

Table of Contents

  1. Overview
  2. Code Quality
  3. Testing
  4. Security
  5. Code Review
  6. Deployment
  7. Acceptance
  8. Documentation
  9. Checklist Summary
  10. Change History

Overview

Purpose

The Definition of Done (DoD) establishes the minimum quality bar that
every user story must clear before it can be marked as complete. It
acts as a shared contract between the development team, Product Owner,
and stakeholders, ensuring that "done" means the same thing to everyone
and that no story ships without meeting the team's agreed-upon standards.

When It Applies

The DoD is evaluated when a developer believes a story is complete and
before it moves to the "Done" column on the board. Every criterion must
be satisfied; partial completion means the story is not done. The
Scrum Master and team are responsible for holding each other accountable
to the DoD during sprint review and retrospective.

Relationship to Definition of Ready

The DoD complements the
Definition of Ready.
Where the DoR ensures stories enter a sprint with enough clarity, the
DoD ensures stories exit with enough quality. Together they form the
quality bookends of the sprint.

Code Quality

Compiles and Deploys Successfully

  • All code compiles without errors in the target sandbox or scratch
    org.
  • The deployment completes successfully with no failed components.

Passes Salesforce Code Analyzer

  • Code passes
    Salesforce Code Analyzer
    using the project's ruleset (salesforce.xml).
  • No severity 1 or severity 2 violations remain.
  • Any suppressed warnings (@SuppressWarnings) are documented with
    justification.

Follows Project Coding Standards

  • Apex code complies with the project's
    Apex Coding Standards,
    including naming conventions, class structure, design patterns,
    ApexDoc on all public/global classes and methods, and no
    hardcoded IDs or magic numbers.
  • LWC code complies with the project's
    LWC Coding Standards,
    including component architecture, SLDS usage, and template
    directives.
  • All code is formatted using the project's Prettier configuration.

Testing

Testing Standards Met

  • All Apex tests comply with the project's
    Testing Standards:
    90% minimum coverage (100% target), 1:1 test-to-method mapping,
    and positive, negative, and bulk (200+ record) scenario coverage.
  • Coverage is verified using sf apex run test --code-coverage.

Governor Limit Compliance Verified

  • The solution operates within
    governor limits
    at expected data volumes (SOQL queries, DML statements, CPU time,
    heap size).
  • Where large data volumes are involved, an appropriate async pattern
    (Batch, Queueable, Platform Events) has been implemented and tested.

LWC Jest Tests (if applicable)

  • Jest tests are written for all LWC components using
    @salesforce/sfdx-lwc-jest.
  • Wire adapters and Apex calls are mocked.
  • DOM rendering, event handling, and public API (@api) methods are
    tested.

All Tests Pass

  • All Apex tests pass in the target sandbox:
    sf apex run test --test-level RunLocalTests.
  • All LWC Jest tests pass: npm test.
  • No skipped or ignored tests without documented justification.

Security

CRUD and FLS Enforced

  • All SOQL queries use WITH SECURITY_ENFORCED or results are
    processed through Security.stripInaccessible().
  • CRUD permissions are checked before DML operations on objects that
    the running user may not have access to.

Sharing Model Declared

  • Every Apex class that performs SOQL or DML declares a sharing model:
    with sharing, without sharing, or inherited sharing.
  • without sharing is used only when justified, approved, and
    documented, with the logic isolated in a dedicated class.

No SOQL Injection

  • Dynamic SOQL uses bind variables exclusively.
  • When dynamic query construction is unavoidable,
    String.escapeSingleQuotes() is applied to all user-supplied input.

No Unsafe DOM Manipulation (LWC)

  • LWC components do not use innerHTML with user-supplied input.
  • Data binding and lightning-formatted-* components are used instead
    of raw HTML injection.

Code Review

Pull Request Created and Complete

  • A Pull Request is created following the project's
    Git Branching Strategy,
    using a promotion branch from the target environment branch.
  • The PR title includes the story number and a descriptive summary.
  • The PR description includes the story link, summary of changes,
    testing checklist, and any dependencies or related PRs.

Peer-Reviewed and Feedback Addressed

  • At least one peer has reviewed and approved the PR.
  • Review covers correctness, standards compliance, security, and
    performance.
  • All review comments are resolved: accepted and implemented, or
    discussed and documented as intentional.

Deployment

Dry-Run Validation Passes

  • sf project deploy start --dry-run succeeds against the target
    environment with no errors.
  • All Apex tests pass during validation.
  • Metadata deployment order has been verified (e.g., objects before
    flows, fields before validation rules).

Destructive Changes Approved

  • Any destructive changes (field deletions, object removals, flow
    deactivations) have documented approval from the technical lead or
    architect.
  • A rollback plan exists for destructive changes.

Post-Deployment Steps Documented

  • If the deployment requires manual steps after completion (data
    migrations, permission assignments, cache invalidation, flow
    activation), they are documented in the story or PR.
  • The person responsible for executing post-deploy steps is identified.

Promotion Branch Workflow Followed

  • The promotion branch was created from the target environment branch.
  • Conflicts were resolved in the promotion branch, not the feature
    branch.
  • The promotion branch was tested before merging to the environment
    branch.

Acceptance

All Acceptance Criteria Met

  • Every acceptance criterion defined in the story has been verified
    and can be demonstrated.
  • Edge cases identified in the acceptance criteria have been tested.

Product Owner Review

  • The Product Owner or Business Analyst has reviewed the completed
    work and confirmed it meets expectations.
  • Any deviations from the original requirements are documented and
    approved.

Demo Completed (if required)

  • The feature has been demonstrated to stakeholders during sprint
    review or an ad-hoc demo, as required by the team's process.
  • Feedback from the demo is captured and, if actionable, logged as new
    stories in the backlog.

Documentation

Technical Documentation Updated

  • If architectural decisions were made, they are documented (decision
    records, design docs, or inline comments).
  • README or inline documentation is updated for any new reusable
    components, utilities, or services.
  • If the story introduced new patterns or modified existing standards,
    the relevant standards documents have their change history updated.

Checklist Summary

Use this checklist before moving a story to "Done."

Quality Checklist

  • [ ] Code compiles and deploys to target sandbox
  • [ ] Passes Salesforce Code Analyzer (no sev 1 or 2 violations)
  • [ ] Follows project coding standards (Apex, LWC, Prettier)

Testing Checklist

  • [ ] Testing standards met (coverage, method mapping, scenarios)
  • [ ] Governor limit compliance verified at expected data volumes
  • [ ] LWC Jest tests written and passing (if applicable)
  • [ ] All tests pass in target sandbox

Security Checklist

  • [ ] CRUD/FLS enforced on all queries and DML
  • [ ] Sharing model declared on all classes with SOQL/DML
  • [ ] No SOQL injection (bind variables or escapeSingleQuotes)
  • [ ] No innerHTML with user input in LWC

Review Checklist

  • [ ] PR created with complete description per branching strategy
  • [ ] Peer-reviewed, approved, and all feedback addressed

Deployment Checklist

  • [ ] Dry-run validation passes with correct metadata ordering
  • [ ] Destructive changes approved (if any)
  • [ ] Post-deployment steps documented (if any)
  • [ ] Promotion branch workflow followed

Acceptance Checklist

  • [ ] All acceptance criteria met and verified
  • [ ] Product Owner / BA has reviewed and approved
  • [ ] Demo completed (if required by team process)

Documentation Checklist

  • [ ] Technical docs and change history updated (if applicable)

Change History

Version 1.2 -- 2026-02-20

  • Merged ApexDoc and No Hardcoded Values into Follows Project Coding
    Standards (already covered by linked standards docs)
  • Collapsed test coverage, method mapping, and scenario coverage into
    single Testing Standards Met item with link to Testing Standards
  • Merged PR Description Complete into Pull Request Created
  • Merged Change History Maintained into Technical Documentation Updated
  • Reduced checklist from 29 items to 22

Version 1.1 -- 2026-02-20

  • Added governor limit compliance verification to Testing section
  • Added metadata deployment order verification to Deployment section
  • Items moved from Definition of Ready where they were premature
    design decisions; they are now validation checks in DoD

Version 1.0 -- 2026-02-20

  • Initial release of Definition of Done documentation

Last Updated: 2026-02-20
Version: 1.2