- Related reading: Following FTAM By Expanding DoD VS. Becoming A Hostage To Traditional Org Structure.
- Definition of Ready (DoR) Example
Maturity of Definition of Done (DoD) has been the area of focus for many teams and organizations.
Expansion (maturation) of DoD can be aligned with a Feature Team Adoption Map (FTAM), and it is covered on this page. In simple words, the more inclusive/comprehensive is a team’s DoD (in essence, it follows, how a feature/product team expands its technical capabilities), the more mature it is. Therefore, upon a sprint’s completion, a team is much closer to being able to release a PSPI.
Here is another important question: What about Definition of Ready (DoR)?
Does DoR’s inclusion/expansion follow the same logic, as that of DoD? For example, if a team lists too many conditions-to-be-met on a DoR checklist, widely expanding and making it very comprehensive, does it mean that a team’s DoR becomes more mature, similarly, to a DoD, or less mature?
It appears that are heavily loaded (very inclusive) DoR, could be a sign of low maturity. If a team feels that it needs to fill in too many check boxes on a DoR list, it usually means that some/all of the following problems could be present:
- There is no clear understanding of how to make a PBI sprint planning-ready
- There is a lack of knowledge of how to split PBIs and ensure that each PBI meets INVEST-able criteria
- There is lack of knowledge of how to simply and reliably estimate and forecast work
- There is fixation/psychological dependency on tracking tools, and many of its fields that must be populated, in order to make a PBI sprint-planning ready
- There is a very strong culture of internal contractual relationships (“us vs. them”) between R&D and business, with the former wanting to make sure that the latter has provided every single piece of information about a PBI, before development begins (no room for intra-sprint discussions)
- Related to the above, there is fear that during a sprint, customers and users will not be available to teams, to provide clarifications and details
- There is a lack of trust between teams and its Product Owner, nor is there enough room for negotiation
- There is a ‘broken telephone’ game, with managers and leads giving unrealistic and aggressive promises to business, and speaking on behalf of product teams. As a result, there is fear by product developers that if they fail to deliver on promises, they may face repercussions that will impact their individual performance
- Related to the above and extremely critical: if individual performance/efficiency is linked to compensation and promotion, there will be cases of risk aversion behavior and numbers gaming
- There is organizational pressure to collect vanity metrics (velocities/story points, capacities, dependencies, risks, etc.) and interference by redundant organizational layers, such as PMO and alike structures
- There is fear of facing unresolvable external dependencies and discovering shortage of skills in the middle of a sprint
Because of the above, it is not uncommon to see that DoR lists the whole myriad of checks & balances that are trivial in nature and are often an indicator of a deep systemic problems. As a team’s DoR gradually matures, it gravitates towards simpler, lighter-weight version, with the focus on things that truly matter and consistent with a team’s agility and product centricity.
The graphic at the top of the page gives an illustration how a team’s DoR can mature over time.
Example of Definition of Ready (DoR)
1.Business value is understood.
- Customer problem is clear.
- Expected outcome is known.
- Success criteria are understood.
- Product Owner can explain the purpose.
- Stakeholders are identified (if needed).
2. Story Quality
- Story follows INVEST where practical.
- Story is vertically sliced.
- Story is small enough for one Sprint.
- Story delivers customer-visible value.
- Story is testable.
- Story is sufficiently independent.
3. Shared Understanding
- Team has discussed the item.
- Major questions are answered.
- Scope boundaries are understood.
- Remaining uncertainty is acceptable.
- Team is confident enough to start.
4. Acceptance Criteria
- Acceptance criteria exist.
- Acceptance criteria are clear and testable.
- Happy path is covered.
- Important edge cases are identified.
- Non-functional expectations are known (when applicable).
5. Estimation & Forecasting
- Story has been relatively estimated (if estimation is used).
- Story fits within a Sprint.
- Oversized items have been split.
- Complexity is sufficiently understood.
6. Dependencies & Risks
- Critical dependencies are identified.
- Blocking dependencies are removed where possible.
- Major assumptions are known.
- Significant risks are visible.
- Required external support is available.
7. Technical Readiness
- Technical approach is sufficiently understood.
- Major architectural concerns have been discussed.
- Necessary spikes or research are completed.
- Required environments, APIs and infrastructure are available.
8. Testing & Quality
- Test approach is understood.
- Test data is available (if needed).
- Required test environments exist.
- Automation approach is understood (where appropriate).
9. UX & Design
- UX designs or mockups are available (when needed).
- Accessibility expectations are identified.
- User interactions are sufficiently understood.
10. Product Backlog Health
- Item is appropriately prioritized.
- Item has been recently refined.
- Item is still relevant.
- Product direction has not changed significantly.
11. Team Readiness
- Required skills exist within the team.
- Required expertise is available.
- Collaboration needs are understood.
- Team believes it can complete the work.
12. Operational Considerations
- Security implications are understood.
- Compliance or regulatory needs are identified.
- Deployment constraints are known.
- Operational impacts have been discussed.
Common Definition of Ready Anti-Patterns
These often indicate organizational complexity rather than true readiness:
- BRD or extensive documentation required.
- Complete technical design finalized upfront.
- All implementation tasks created before Sprint Planning.
- Tasks assigned to individual developers before the Sprint.
- Every dependency documented for governance.
- Mandatory management sign-offs.
- RACI charts or governance artifacts required.
- Capacity and velocity become weaponized metrics.
- Exact completion dates committed before work starts.
- Story Points used primarily for executive reporting.
- Extensive upfront risk documentation.
- Heavy approval workflows before development can start.