Skip to main content

Definition of Ready (DoR)

Introduction​

The Definition of Ready (DoR) establishes the criteria that a user story or task must meet before the development team commits to working on it. A well-formed work item that meets these criteria helps ensure smooth development, reduces ambiguity, and minimizes delays due to missing information or unclear requirements.

Purpose​

The purpose of this Definition of Ready is to:

  1. Ensure work items are sufficiently detailed and clear before development begins
  2. Minimize interruptions and delays during development due to missing information
  3. Create a shared understanding between product, development, and quality teams
  4. Provide a framework for consistent ticket creation and refinement
  5. Increase overall team productivity and quality of delivered features

Definition of Ready Criteria​

For a user story or task to be considered "Ready for Development," it must meet the following criteria:

1. Well-Formed User Story​

A complete user story must include:

  • Summary: Clear, concise, and descriptive ticket summary/title that summarizes the work item
  • User Story: Written in the format "As a [user role], I want [goal], so that [benefit]"
  • Acceptance Criteria: Specific, measurable, and testable conditions that must be satisfied for the story to be considered complete

2. Essential Sections​

Each ticket must contain the following sections:

  • User Story: The clearly defined user story as described above
  • Acceptance Criteria: Detailed list of requirements that must be fulfilled

When applicable, these additional sections are required:

  • Context: Background information needed to understand the purpose and scope
  • Out of Scope: Clear indication of what is not part of the current work item
  • Resources: Links to relevant documentation, designs, or references

3. Properly Managed in Jira​

  • The ticket has been properly groomed and contains the Groomed label
  • The ticket has an assigned FixVersion (release/sprint version)
  • The ticket is linked to an appropriate Epic
  • The priority rating is accurate and reflects the true importance of the work
  • The work has been sized appropriately (time estimate)
  • Estimates have been aligned upon by the development team
  • Complex stories are broken down into smaller, manageable pieces

4. Clear Deliverables​

  • The expected outputs or deliverables are clearly defined
  • Technical approach or solution has been discussed and documented when applicable
  • Dependencies on other work items or systems are identified and resolved or mitigated

5. Testable Requirements​

  • Acceptance criteria are testable and verification methods are clear
  • Test scenarios or cases are identified (automated vs. manual testing)
  • Quality expectations are defined

6. Design and Technical Information​

  • Design artifacts are available if needed (wireframes, mockups, etc.)
  • Technical constraints or non-functional requirements are documented
  • API specifications or data models are defined when applicable

7. Team Agreement​

  • The development team has reviewed and understands the work
  • Technical feasibility has been confirmed
  • Stakeholders have approved the requirements

Example of a Ready Ticket​

Here's an example that demonstrates a properly formatted ticket that meets the Definition of Ready criteria:

Example of a Jira Ticket that meets DOR

Summary: Test Environment: Build sample WordPress site for testing bundled scheduler tool​

Description​

User Story​

As a quality engineer, I want a sample WordPress site deployed for testing our bundled scheduler tool, so I can validate the scheduler's functionality in a production-like environment.

Context​

  • We need a basic WordPress site that represents a typical customer implementation
  • This will serve as one of our primary testing environments
  • The site should follow WordPress best practices for script integration
  • This complements our planned Shopify test environment

Acceptance Criteria​

  • Deploy a basic WordPress site with:
    • Clean, minimal theme
    • Sample content pages
    • Basic navigation structure
  • Configure WordPress admin access:
    • Create test admin account
    • Document credentials in 1Password
  • Setup development tools:
    • Enable WordPress debug mode
    • Install developer plugins if needed
  • Document site details:
    • Deployment URL
    • Admin access steps
    • Local development setup
    • Known limitations

Out of Scope​

  • WordPress theme customization
  • Plugin development
  • Performance optimization
  • Content strategy

Resources​

Verification Process​

During sprint planning or backlog refinement, the team will verify each work item against this Definition of Ready. Items that don't meet the criteria will be sent back for further refinement before being accepted into a sprint.

The Product Owner, Spencer, is responsible for ensuring that all work items meet the Definition of Ready before they are presented to the development team for planning.