What is the difference between Definition of Done (DoD) AND Definition of Ready (DOR)?

Definition of Done

According to the 2020 Scrum Guide:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

To put it simply: The user story is really Done when it meets all the criteria of the DoD.

So when the PO asks : is the user story done? Your answer is “YES“, and not “yes but we are only missing the unit tests“.

If you are looking for inspiration, here are some criteria of a DoD for a user story:

• Functional tests are executed
• Acceptance tests are executed
• No critical bugs
• Code coverage over 80%
• Unit tests completed
• PO saw a demo and gave the OK

Take the first letters of each criteria and it spells FANCUP. Here’s an image to help you remember it :

Definition of Ready

The  DoR comes before applying the DoD. The 2020 Scrum Guide only mentions this:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

The Scrum Guide doesn’t explicitly call it the Definition of Ready, but you can somehow read it between the lines.

The main goal is to make sure the user story is in a state of “ready” so that you can easily take it in the Sprint Planning. For those who haven’t defined the DoR, how many times did you arrive at a Sprint Planning, spend 30min to discuss a user story to only realize that the user story isn’t ready to be worked on? That’s what the DoR is trying to address.

• user story is broken down as small as possible
• acceptance criteria is clear
• out of scope items are defined
• it has been presented to the Development team
• user story has story points

When does the team define them?

Ideally, you should have a DoD and DoR before starting Sprint1 in a perfect world… but then again we aren’t perfect .

As long as you do it and revise it every once in a while, you’re good.

The revision part is important because the team will evolve and they will adapt the DoR and DoD as a consequence. When is a good time to revise them?

At the Sprint Retrospective!!

Who participates in the DoD and DoR?

• the Development team
• the PO
• the Scrum Master (as facilitator)

It is really the PO and Development Team that decides what goes in a DoD and DoR. The SM is there to facilitate the meeting. Avoid doing the meeting without the PO.

Can we have many definitions of done?

Some people will categorically say NO but then again , if the goal is to help your team be more efficient and improve the quality of the increment, why not?

Here are some examples where you may want to consider the DoD… or if you don’t want to use that term, call it the Definition of Complete 

• what do you need in order to publish to PROD (documentation, NFR tested, automated end-to-end tests …)
• do different types of user stories need different DoD: e.g. some are only for API, some are only for front-end
• do you want to distinguish the DoD between dev and qa?