“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, 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)
- Meet the INVEST criteria
- Independent (of all others)
- Negotiable (not fixed feature contract)
- Valuable (delivering it provides value)
- Estimable (with decent approximation)
- Small (i.e. fitting in a single iteration)
- Testable (that can be specified along)
- Specify acceptance criteria with examples
- Be directly actionable without waiting-time.
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”.
In essence, DoR aims to prepare what must be done before starting the work, while letting what be done just-in-time happens in that way, optimizing for Quality at Speed.
In that respect, some teams can decide to add other criteria in their DoRs:
- Architecture review completed
- User interface mock-ups are done (usually, they enrich the use-cases)
- Internal or external dependencies are identified and solved.
The Definition of Ready (DoR) is a useful method for aligning the actors on the work required before proceeding with its implementation, and favors exchanges in the team especially to help identify dependencies and requirements that can be missed working alone.
The DoR is different from the Definition of Done (DoD) that ensures the effective implementation of the story meets a number of conditions to be complete.
Why using DoR in Quality Engineering
Quality Engineering is the paradigm constraining the entire lifecycle to Quality at Speed software to continuously deliver valuable software with the 5 domains of MAMOS, the Quality Engineering Framework: Methods, Architecture, Management & culture, Organization, Skills.
The domain of Methods is critical to streamline software activities for short cycles of valuable iteration. Software production is the result of the actor’s collaboration, improved by the organization of their actions around rituals favoring rapid alignment and understanding.
The Definition of Ready is part of the Methods domain contributing both to Quality and Speed, especially before the actual software implementation.
How DoR contributes to Quality
Quality is subjective to each person, requiring to define its requirements and criteria when producing software in a team. Each software increments having specific attributes, there is no one-size-fits-all quality or use-cases to reuse for every story.
The Definition of Ready is acting as the systematic Quality counter-force during the lifecycle checking for the minimal requirements. Its simplicity and capability of adaptation ease its deployment across the different software teams.
DoR contributes to Quality being:
- Result-oriented defining the “Ready for Quality at Speed” state
- Systematic with a checklist applicable to processes and tasks
- Scalable with a simple model that can start small and expand.
How DoR contributes to Speed
Organizations in search of economies of speed have no time to lose. They have to deliver valuable software increments in short cycles, maximizing the value and time-to-market balancing an effective preparation and execution.
The Definition of Ready acts as a balance to force the minimal requirements for actionable stories that can then be implemented with velocity, minimal dependencies and rework. The DoR rewards teams with speed when they correctly invest their time in upfront planning and analysis.
DoR contributes to Speed with:
- Focus on minimal pre-conditions, limiting non-necessary work
- Rhythm with a systematic approach to backlog items verification
- Asynchronicity as being a checklist easily shared and updated
- Visibility providing the status of the backlog items anytime.
How to start with DoR in Quality Engineering
The Definition of Ready (DoR) is a practice that can be implemented straight from the start in Quality Engineering. It should start with a simple model for the most valuable tasks, to then extend its deployment for more tasks and multiple teams.
The process to implement the Definition of Ready is:
- Gather the organization goals and values
- Identify the transversal software stakeholders
- Organize workshops to draft a Definition of Ready
- Test it with minimal checklist in your or a few stories
- Continuously measure, adapt and share to improve
Starting with a minimal checklist is more effective to adapt faster to the context:
- Define the business value and users
- Independent of all others
- Negotiable, not a fixed feature contract
- Estimated with decent approximation
- Small enough to fit in a sprint
- Testable with acceptance criteria
- Be directly actionable questioning specific needs.
The DoR checklist must always state that the points are minimal guidelines, not blocking states impacting the flow of iteration. The judgment of the team on the Definition of Ready is important to keep as the decision-point, instead of the sole checklist.
Teams can then enrich their checklist gaining more maturity along the software lifecycle with:
- User interface designs
- Architecture review
- Business rules review
- Use-cases in TDD style
- How to demo defined
- Definition of Done review
- Internal dependency removal
- External dependency removal
- Knowledge expert review
- Non-functional requirements (e.g. privacy, security)
- Minimal test automation for DevOps quality gates
- Alerting rules.
The attention point is to stick to the principle of “minimal quality gates” to avoid blocking the flow for non-applicable rules or trying to reach 100% level. If the checklist starts to be too exhaustive, it probably includes items that should remain reviewed or for just-in-time implementation.
A balanced way to have more criteria while maintaining the flow is to:
- Define a rank of DoR level (e.g. Gold, Silver, Bronze)
- Decide the acceptable rank per type of tasks.
The teams can then decide the readiness per acceptable rank. For example, an important change on the main customer journey will require the Gold DoR, while a minor change in an administrator area would be sufficient with the Bronze level.
The Definition of Ready can result in a checklist per task as follows:
DoR within MAMOS, the Quality Engineering framework
The Definition of Ready is an essential methodology to start and expand Quality Engineering within the organization.
The combination of DoRs with OKRs and Definition of Done focuses the team on the most important deliverables with Quality at Speed.
We must keep in mind that the Definition of Ready is the counter-force defining the minimal requirements to consider a backlog item as “Ready for Quality at Speed implementation”.
So if you discover items being implemented without a readiness assessment, just stop them to assess them through the minimal DoR quality gates.
It’s about stopping things when they start with how.
References
Walking Through Definition of Ready, Scrum.org.
Doug Rose (2015), Leading Agile Teams. Project Management Institute.
Scrum Tutorial, The Definition of Ready, Knowledgehut.com.
What is the definition of ready in Scrum, Visual paradigm.
Mike Cohn (2016), The Dangers of a Definition of Ready. MountainGoatSoftware.