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.