Definition of Ready

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

• The design follows Lightning Design System patterns and utility classes.
• Custom CSS is minimized; SLDS classes and design tokens are preferred, as defined in the project's LWC Coding Standards.

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.2 -- 2026-03-26

• Normalized markdown formatting and link references for consistency and readability.
• Clarified standards links for SLDS, WCAG, and LWC coding guidance.

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-03-26 Version: 1.2