Definition of Ready

Criteria that a user story or work item must meet before it can be pulled into a sprint for a Salesforce project

Category: Agile
Tags: agile definition-of-ready salesforce scrum sprint-planning

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

Table of Contents

  1. Overview
  2. General Criteria
  3. Salesforce-Specific Criteria
  4. Apex-Specific Additions
  5. LWC-Specific Additions
  6. Checklist Summary
  7. Change History

Overview

Purpose

The Definition of Ready (DoR) establishes the minimum criteria a user
story or work item must satisfy before the team can pull it into a
sprint. Its purpose is to reduce mid-sprint ambiguity, prevent
incomplete requirements from consuming capacity, and give the
development team confidence that a story is actionable on day one of the
sprint.

When It Applies

The DoR is evaluated during backlog refinement and sprint planning. A
story that does not meet all applicable criteria should remain in the
backlog until the gaps are resolved. The Product Owner, Business
Analyst, and development team share responsibility for ensuring stories
meet the DoR before they enter a sprint.

General Criteria

These criteria apply to every user story regardless of technology or
work type.

Acceptance Criteria Defined

  • Acceptance criteria are written in clear, testable language.
  • Each criterion describes a specific, observable outcome rather than
    an implementation detail.
  • Edge cases and error scenarios are addressed where applicable.

Story Estimated

  • The team has estimated the story using story points (or the agreed
    estimation method).
  • The estimate reflects a shared understanding of scope and complexity.
  • If the estimate exceeds the team's sprint capacity threshold, the
    story must be decomposed into smaller stories.

Dependencies Identified

  • All dependencies on other teams, stories, packages, third-party
    APIs, or data migrations are documented.
  • All dependent stories are linked in the work tracking tool
    (predecessor/successor, blocked-by, or relates-to) so dependency
    status is visible on the board and in reports.
  • Blocking dependencies have a resolution plan with an expected
    completion date.
  • Non-blocking dependencies are noted so the team can sequence work
    appropriately.

No Blockers

  • All prerequisite stories are complete or will be complete before
    this story is started.
  • Access to required systems, environments, and credentials is
    confirmed.
  • Open questions with stakeholders have been answered or have a
    documented path to resolution within the sprint.

Story Sized for One Sprint

  • The story can be completed, tested, and demonstrated within a
    single sprint.
  • If the story is too large, it has been decomposed into independently
    deliverable increments.

Mockups and Wireframes (if UI work)

  • Visual designs, wireframes, or mockups are attached to the story.
  • Interaction patterns (hover states, error states, loading states)
    are documented.
  • Responsive behavior expectations are defined.

Business Context Understood

  • The team understands the business value and the "why" behind the
    story.
  • The user persona or audience is identified.
  • Success metrics or KPIs are defined where applicable.

Salesforce-Specific Criteria

These criteria address Salesforce platform considerations that should
be understood before development begins. The focus here is on
awareness and requirements -- technical design decisions belong in the
sprint, not in refinement.

Platform Impact Assessed

  • New or changed custom objects, fields, validation rules, flows, and
    record types are identified.
  • Required metadata changes are listed: permission sets, page layouts,
    record type assignments, custom labels, and custom metadata types.
  • Integration touchpoints are documented: external systems, endpoints,
    authentication methods, and expected payloads.
  • Estimated data volumes are noted so the team can factor scale into
    the estimate.

Environment Ready

  • A development sandbox or scratch org is available and assigned.
  • The sandbox is refreshed or the scratch org definition file is
    up-to-date with required features and settings.
  • Any required managed packages are installed in the target
    environment.

Risk Factors Flagged

  • Large data volumes that may require async processing are called out.
  • Security requirements are captured at the requirements level:
    which users or roles should have access, and whether record-level
    restrictions apply.
  • Destructive changes (field deletions, object removals) are flagged
    and require documented approval before sprint commitment.

Apex-Specific Additions

When the story involves Apex development, these additional criteria
apply.

Existing Trigger Landscape Known

  • The team is aware of whether triggers already exist on the affected
    objects so new logic can be planned within the existing handler
    structure per the project's
    Apex Coding Standards.

Async or Callout Needs Flagged

  • The story notes whether the work involves callouts to external
    systems or is expected to process volumes large enough to require
    async execution.
  • This is an awareness flag for estimation -- the specific async
    pattern (Batch, Queueable, Platform Events) is a design decision
    made during the sprint.

LWC-Specific Additions

When the story involves Lightning Web Component development, these
additional criteria apply.

Component Placement Identified

  • The target Lightning page, community page, or utility bar placement
    is documented.
  • The component's metadata configuration (js-meta.xml) targets are
    defined (e.g., lightning__RecordPage, lightning__AppPage).

SLDS and Design Token Compliance Reviewed

Accessibility Requirements Noted

  • Required ARIA attributes, keyboard navigation, and screen reader
    behavior are documented.
  • Color contrast and semantic HTML requirements are identified.
  • The story references
    WCAG 2.2 Level AA compliance where
    applicable.

Checklist Summary

Use this checklist during backlog refinement and sprint planning.

General

  • [ ] Acceptance criteria are clear and testable
  • [ ] Story is estimated
  • [ ] Dependencies are identified, linked, and have resolution plans
  • [ ] No unresolved blockers
  • [ ] Story fits within one sprint
  • [ ] Mockups/wireframes attached (if UI work)
  • [ ] Business context and "why" are understood

Salesforce Platform

  • [ ] Platform impact assessed (objects, fields, metadata, integrations)
  • [ ] Environment ready (sandbox or scratch org available)
  • [ ] Risk factors flagged (data volume, security, destructive changes)

Apex (if applicable)

  • [ ] Existing trigger landscape known
  • [ ] Async or callout needs flagged

LWC (if applicable)

  • [ ] Component placement identified
  • [ ] SLDS compliance reviewed
  • [ ] Accessibility requirements noted

Change History

Version 1.1 -- 2026-02-20

  • Collapsed Salesforce-specific criteria from 7 subsections into 3
    broader readiness checks (Platform Impact, Environment Ready, Risk
    Factors)
  • Removed implementation-level items (governor limit strategy,
    deployment ordering, sharing keywords, test data strategy) -- these
    belong in the Definition of Done
  • Simplified Apex additions to focus on awareness over design
  • Added dependency linking requirement

Version 1.0 -- 2026-02-20

  • Initial release of Definition of Ready documentation

Last Updated: 2026-02-20
Version: 1.1