Skip to content

Commit

Permalink
Merge pull request #45 from nkdAgility/update/dor
Browse files Browse the repository at this point in the history
Update/dor
  • Loading branch information
MrHinsh authored May 9, 2023
2 parents 3a38ec9 + 841fa02 commit a6c9469
Showing 1 changed file with 22 additions and 2 deletions.
24 changes: 22 additions & 2 deletions src/collections/_practices/definition-of-ready-dor.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,11 +8,31 @@ recommendedContent:
redirect_from:
- practices/Definition-of-Ready-DoR.html
---
**WARNING: Definition of Ready can result in significant anti-patterns in teams.**
From the perspective of Scrum, the idea of Ready, as applied to a Backlog Item, represents everyone's (Developers, Product Owner, & Stakeholders) understanding of what is needed to implement that Backlog Item. Since this is subjective and not objective, having a definition of what constitutes ready is not possible.

The danger of having a defined definition of Ready (DoR) is:

- **False sense of Ready** - First that it creates a false sense of Ready that encompasses the objective points that we can focus on, but misses the subjective. This can lead to false gating, where participants hold each other accountable for failing to achieve something that was not defined in the first place.
- **Neglecting Refinement**
- **False Equivalence with DoD** - Using the DoR terminology generally leads participants to feel that the DoD and the DoR have an equivalence. This is dangerous as the DoD is an absolute boolean proposition, while the subjective nature of the DoR may lead it to be only partially implemented. If it's OK to only partially achieve the DoR, the logical fallacy is that the DoD can also be partially implemented.

A solution that may enable the effective use of this practice may be to a different formula of naming to create disambiguation between the DoR and the DoD.

## Backlog Candidacy Test

Every candidate Backlog Item should have:

- has a clear outcome or objective.
- contains a clear hypothesis.
- defignes clear telemetry to be collected.

Once candidacy is achieved then the Team & Stakehodlers can determin Ready with conversation.

## Rule of Thumb

_As a general rule Developers should not take Backlog Item into a Sprint that they do not fully understand and agree, as a team, that there is a reasonable likelihood of being successful._

A Definition of Ready often results in a lack of refinement with the Scrum Team and thus a lack of understanding of the Backlog Items. Refer to the [Backlog Item Format](/Project-Management/Agile-Ways-of-Working/Complementary-Practices/Writing-Backlog-Items) that you have chosen for what might be contained within it. If you MUST have a DoR then consider:
## INVEST

- I (Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
- N (Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.
Expand Down

0 comments on commit a6c9469

Please sign in to comment.