Gradual Maturation (Simplification) of Definition of Ready (DoR)


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.

Leave a Comment

Please help us fight spam. Lets make sure you are not a robot !!!