“Plan the work, work the plan.”
It sounds like a simple principle to apply in software. Yet, we still wonder why so much waste and rework is found in software implementation due to poor planning.
Investment time upfront in the software lifecycle — known as Shift-left — enables to improve the quality of software increments to be worked on.
The question is what to plan, scope and formalize with minimal effort?
The Definition of Ready (DoR) is a practice for defining the minimum viable conditions a task must fulfill before implementation, especially user-stories.
This article shares how the Definition of Ready fits in the Quality Engineering paradigm to help you deliver Quality at Speed software.
Follow the QE Unit for more exclusive Quality Engineering from the community.
What is the Definition of Ready (DoR)
The tendency of teams is to rush through implementation, bypassing essential steps likely leading to issues later on: simple rework, bugs fix, or to a complete restructuring if a strong architectural requirement has been missed.
The Definition of Ready (DoR) is a counter-force defining the minimal requirements to consider a backlog item as “Ready for Quality at Speed implementation”.
— Antoine Craske, The Definition of Ready in Quality Engineering.
The key elements of a Definition of Ready (DoR) requires that all stories must:
- Define the business value and users
- Have an estimate (in sizing like t-shirt, number or days)
- Specify acceptance criteria with examples
- Be directly actionable without waiting-time
- Meet the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
The Definition of Ready (DoR) is a “just-enough” quality gate ensuring the essential inputs are present to proceed with a story; it does not aim to define the “100% ready”.