What are DOD and DOR in Scrum, and Why Should I Use Them?

What is DOD and DOR in Scrum, and why should I use them?

Ceremonies and techniques like “Definition of Done,” and “Definition of Ready” are common across many different types of agile teams and frameworks, not just scrum, they are often implemented as an “agile best practice.” Neither of these are new to the software business - frameworks like CMMI and PMBOK have been using these, with different names, for decades.

They are both a type of “validation” and are quite valuable.  And positioning them as "ceremonies" allows them to act as a control so that all team members agree to move forward.  Good stuff, and much needed.

Definition of Ready, or DOR, and sometimes called "Ready for Work," is a set of criteria that must be satisfied in order for an Epic or a Story to be accepted by the team. The story should be instantly “actionable,” and ready to build. This happens BEFORE you build it, so you can think of this as “pre-validation.”
According to the SW Engineering Institute, over 70% of defects are injected at the point of requirements acceptance by the team, mostly because they fail to be validated in one or more of the established criteria. The most common method for doing this is INVEST:

1. Is the Story Independent?
2. Is the story Negotiable (with the team, product owner, etc)
3. Is the Story Valuable?
4. Is the Story Estimable?
5. Is the Story sized correctly (or “small”)?
6. Is the Story Testable?

Other companies use SMART Goals, or their own set of criteria. Some companies use a meeting like “Three Amigos,” or “Three Diverse Humans” to do this as well. Boeing uses the CAM method (“Cranial Analysis Method”), which is like Three Amigos but with people who say they’re really smart :)
The important part is that they address the question “Is this a GOOD story?”
Definition of Done, or DOD, is the team’s agreement on what it means to complete a story. This happens AFTER you build it, so you can think of it as “post-validation.”

1. Typical criterion for DOD are:
2. The Story is Tested
3. All defects are fixed
4. The Product Owner has approved it
5. The documentation is complete

Developing a good, solid set of criteria to validate stories both BEFORE and AFTER you build them is a basic function of software engineering, and there use will help to eliminate defects earlier.
There is more information about these, and other agile ceremonies, at agilecxo.org.

Good luck!