Practice : Definition of Ready and Done

Purpose and Strategic Importance

Definition of Ready (DoR) and Definition of Done (DoD) are shared agreements that establish the minimum conditions for starting and completing a backlog item. They improve alignment, reduce rework, and ensure consistent quality across the team.

This practice brings discipline and clarity to the delivery lifecycle by promoting a shared understanding of what “good” looks like at both the start and end of work. It enables teams to manage flow more effectively and maintain trust in what’s being delivered.

Description of the Practice

  • Definition of Ready sets the baseline for when a backlog item is ready to enter active development (e.g. clear acceptance criteria, value understood, dependencies identified).
  • Definition of Done sets the quality bar for when an item is truly complete (e.g. tested, reviewed, deployed, documented).
  • These definitions are visible, agreed, and evolved by the team over time.
  • DoR and DoD support predictability, reduce ambiguity, and promote continuous improvement.

How to Practise It (Playbook)

1. Getting Started

  • Collaboratively define initial DoR and DoD criteria with your team during a working agreement session or retrospective.
  • Keep both definitions simple, visible, and easy to reference during refinement and reviews.
  • Pilot the definitions for a few sprints and adjust based on friction points.

2. Scaling and Maturing

  • Use refinement sessions to check if upcoming work meets the DoR before sprint planning.
  • Integrate DoD checks into the Definition of Done in your tooling (e.g. Jira, Azure Boards).
  • Review DoR/DoD periodically to reflect new learnings, risk considerations, or team maturity.
  • Apply DoD at multiple levels: story, feature, and release, as needed.

3. Team Behaviours to Encourage

  • Raise blockers early if DoR isn’t met, rather than starting half-shaped work.
  • Take pride in meeting the DoD—don’t treat it as a tick-box exercise.
  • Use peer reviews or demo sessions to confirm whether items truly meet the DoD.
  • Revisit and evolve definitions together as team norms and responsibilities change.

4. Watch Out For…

  • Overly rigid or bureaucratic definitions that stifle flow or discourage experimentation.
  • Misalignment between what product, engineering, and QA consider “done”.
  • Definitions that exist on paper but aren’t applied in practice.
  • Teams starting work because of external pressure, despite unmet DoR.

5. Signals of Success

  • Less rework or rollback due to incomplete or misunderstood requirements.
  • Teams feel confident about what’s expected when starting or finishing work.
  • Quality issues reduce, and flow stabilises as teams adopt shared guardrails.
  • Retrospectives surface fewer surprises about why work wasn’t accepted or deployed.
  • DoR and DoD evolve organically as the team matures and improves.