PMI Sites
Register
Disciplined Agile
Search

    Definition of Ready and Different Ways to Use It

    A Definition of Ready (DoR) states what is needed for an item to be ready to be worked on by implementation. A DoR basically defines the specifics of the agreement as to what items on the intake process have to contain to have work started by Implementation.

    Why have a definition of ready? A definition of ready is an explicit agreement between the parties involved. This avoids confusion.

    There can be two different definitions of ready – one for the program and one for the team.

    DoRs at the team level are between the product owner and the team. When groups of teams are involved the DoRs are between the product managers and teams.

    DoRs are usually agreed upon by a product owner and a team when used at the team level or between the entire Discovery group (or their representatives) and the Implementation group (or their representatives).

    An example DoR would be that the following work has been done for each item:

    • A problem statement has been filled out. This is useful because people building the function should understand the problem it solves.
    • A solution statement has been filled out. While the request may be obvious to the person making it, it may not be obvious to the person creating the solution.
    • The effect of this item on the end-to-end customer experience has been examined. Many discovery and implementation groups are siloed and don’t consider the end-to-end user experience when building their part of the functionality. It is important that this be considered or the value of the work may be greatly diminished.
    • Any enabling value streams required to set up what is necessary for the function have been considered. Some value streams must be set up in order to be used. This is often forgotten.

    Using DoRs

    DoRs can be used in a number of ways:

    1. a guide representing what before working on an item
    2. an agreement that work will not be done on an item unless the DoR is met. This is an extreme case usually used when there is no intake process and/or the Discovery side is not doing their work well. In this case work not meeting the DoR is placed at the bottom of the intake queue.
    3. an agreement that work should not be done on an item unless the DoR is met. This is an extreme case usually used when there is no intake process and/or the Discovery side is not doing their work well. In this case work not meeting the DoR will be sequenced as normal but will be flagged as not having met the DoR. This can create visibility on the cost and/or need of not doing DoRs.

    DoRs and Classes of Service

    It is not unusual for different classes of service to have different DoRs. However, the essences of the DoRs (being ready to do the job) should be similar as applicable.

    Using DoRs

    A tool should be selected that enables stating whether the DoR for an item has been achieved.  The tool should also enable sorting of the items where those items which have not met a DoR can be sequenced lower than those that have.

    Questions and Answers

    Q: Do i need all of my DoRs to be the same?

    A: No. Each team, or group of teams doing different types of work can have different DoRs. In addition, each team or group of teams can have a different DoR for each class of service.

    Q: What if I can’t get agreement on the DoR?

    A: Nothing prevents a DoR to be “whatever you have.” A DoR is merely an explicit statement of the agreement for what it means to be ready. This can be the product owners judgement.

    Q: I have heard that a definition of ready is both old school and a phases gate approach and shouldn’t be used. What do you say to that?

    A: DoR, like most things, can be mis-used. A DoR as a strict “follow it” can be counter-productive. But most approaches have DoRs, they are just implicit – which is not an improvement.

    Q: What’s an example of a simple DoR?

    A: Developers should never build a story for which they haven’t discussed with the product owner. This may seem obvious but I’ve seen developers want to jump ahead when a PO isn’t available. Much of the time the work is wasted because they didn’t understand the real requirement.

    Common Conflations

    In a Flow/Lean environment DoR is not a stage gate. It is an agreement between those identifying what to work on and those doing the work as to what represents the readiness of an item. A DoR by itself does not state what happens when an item doesn’t meet it.

    DoRs and Classes of Service

    It is not unusual for different classes of service to have different DoRs. However, the essences of the DoRs (being ready to do the job) should be similar as applicable.

    Using DoRs

    A tool should be selected that enables stating whether the DoR for an item has been achieved.  The tool should also enable sorting of the items where those items which have not met a DoR can be sequenced lower than those that have.

    Questions and Answers

    Q: Do I need all of my DoRs to be the same?

    A: No. Each team, or group of teams doing different types of work can have different DoRs. In addition, each team or group of teams can have a different DoR for each class of service.

    Q: What if I can’t get agreement on the DoR?

    A: Nothing prevents a DoR to be “whatever you have.” A DoR is merely an explicit statement of the agreement for what it means to be ready. This can be the product owners judgement.

    Common Conflations

    In a Flow/Lean environment DoR is not a stage gate. It is an agreement between those identifying what to work on and those doing the work as to what represents the readiness of an item. A DoR by itself does not state what happens when an item doesn’t meet it.

    The Definition of Ready Template

    This template is for the Definition of Ready

    This template is sued to document the options provided in it.

    This section is used by people doing DA FLEX to tailor the DoR to their needs. The above descriptions are generic.  While DoRs can be defined in any manner, and the above descriptions are generic, they can be tailored by copying the section below into Word and specifying how things are being used in a particular group, program or team.

    This section (from this point to the end) can be freely copied and modified for use by someone using DA FLEX.

    Name of DoR __________________________________________________

    Level of DoR (group, program, team) ______________________________

    This agreement is between ______________________________________

    The Following must be done to satisfy the Definition of Ready

    ______________________________________________________________

    ______________________________________________________________

    ______________________________________________________________

    ______________________________________________________________

    ______________________________________________________________

    The purpose of the DoR is to be

    (“use DoRs can be used in a number of ways” to be a guide here)

    ______________________________________________________________

    ______________________________________________________________

    ______________________________________________________________

    ______________________________________________________________

    ______________________________________________________________

    April 2023

    Team Lead Overview