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 policy met

  • All Apex tests comply with the project's Testing Policy: 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.3 -- 2026-03-26

  • Normalized markdown formatting and link references for consistency and readability.
  • Updated terminology to align references with the Salesforce Testing Policy hub.

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 policy met item with link to Testing Policy
  • 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-03-26 Version: 1.3