HKSM

A team-agreed checklist that a product backlog item must satisfy before being selected for a sprint. It ensures the item is clear, valuable, estimable, and free of critical blockers so the team can plan and commit with confidence.

Key Points

• A working agreement created collaboratively by the Product Owner and Scrum Team, facilitated by the Scrum Master.
• Serves as an input to Approve, Estimate, and Commit User Stories and to Sprint Planning in SBOK.
• Applied to user stories, defects, technical tasks, and spikes; complements the Definition of Done.
• Evolves through Groom Prioritized Product Backlog and Retrospect Sprint activities.
• Aim is predictability and shared understanding, not bureaucracy; it should be concise and practical.
• If an item does not meet the checklist, it returns to refinement instead of being forced into a sprint.

Purpose

The Definition of Ready (DoR) protects the sprint by ensuring only well-understood, properly sized, and testable items enter the Sprint Backlog. It reduces rework, improves estimation accuracy, and supports stable throughput.

In SBOK-aligned workflows, the DoR connects refinement to planning, acting as a gateway from the Product Backlog to commitment during Approve, Estimate, and Commit User Stories and Create Sprint Backlog.

Key Terms & Clauses

• Clear value statement: the user story articulates who, what, and why, often aligning to INVEST.
• Acceptance criteria: testable conditions are written and understood by the team.
• Sizing and estimate: the story is small enough to complete within one sprint and has an agreed estimate.
• Dependencies identified: external teams, third-party components, and blockers are surfaced and manageable.
• Testability and data: required test data, environments, and access are available or planned.
• Non-functional needs: performance, security, usability, and compliance considerations are noted when relevant.
• Definition of Done alignment: the team believes the item can meet DoD within the sprint.

How to Develop/Evaluate

Co-create the DoR early with the Product Owner, Scrum Master, and Developers. Start with a lightweight list based on common issues and expand only when necessary.

• Draft initial clauses from past planning pain points, escaped defects, and incomplete stories.
• Review and tune the checklist during Groom Prioritized Product Backlog and in Retrospect Sprint.
• Evaluate each backlog item against the DoR during refinement; record gaps as follow-up tasks.
• Keep it visible in the team space or tooling; use simple language and 6–10 concise checks.
• Periodically prune redundant clauses to keep flow fast and focused.

How to Use

During backlog refinement, the team applies the DoR to raise questions, split large items, and clarify acceptance criteria. Items that meet the DoR become candidates for the next sprint.

• Input to Approve, Estimate, and Commit User Stories: only DoR-compliant items are considered for commitment.
• Input to Create Sprint Backlog: selected items move smoothly into tasking and capacity balancing.
• If a clause is unmet, the Product Owner queues follow-up work or defers the item to a later sprint.
• For spikes or research, define a leaner, fit-for-purpose DoR emphasizing a clear outcome and timebox.
• Use a board or tool column labeled Ready to visualize which items qualify for planning.

Example Snippet

Sample DoR checklist for a Scrum Team:

• User story states user, goal, and value in simple language.
• Acceptance criteria are specific, observable, and testable.
• Story is split small enough to finish within one sprint.
• Estimate agreed by the team; high uncertainty is noted or reduced.
• Dependencies and external approvals are identified and manageable.
• Test data and environment needs are addressed or scheduled.
• Relevant non-functional requirements are captured.

Risks & Tips

• Overly strict DoR can slow flow; keep it minimal and value-focused.
• Vague or optional DoR yields rework and missed commitments; apply it consistently.
• Do not use DoR as a contract against the Product Owner; treat it as a collaborative guide.
• Adjust for discovery work like spikes; do not force delivery-style clauses on research.
• Revisit the DoR after planning failures or scope churn to capture learning.
• Ensure DoR and Definition of Done are distinct yet aligned to avoid gaps.

PMP/SCRUM Example Question

During Sprint Planning, the team finds a high-value user story that lacks clear acceptance criteria and has an unresolved dependency on an external API. What should the Scrum Master encourage the team to do?

1. Pull the story into the sprint and define acceptance criteria during execution.
2. Defer the story until it meets the Definition of Ready and is free of critical blockers.
3. Split the story arbitrarily so part of it can be started without criteria.
4. Escalate to senior management to force the external team to remove the blocker immediately.

Correct Answer: B — Defer the story until it meets the Definition of Ready and is free of critical blockers.

Explanation: The DoR is an input to sprint commitment; items lacking acceptance criteria and with unresolved dependencies should return to refinement. Pulling it in risks churn and missed commitments.