Definition of Ready & Definition of Done – so simple and so powerful

Whenever I start working with a new team, one of the first things we do is determine the Definition of Ready as well as the Definition of Done. Defining and using those two artifacts is not overly complicated but saves all involved from a lot of stress down the road.

Nevertheless, I frequently find teams that use neither or don’t even know what they are. Thus, I think it makes sense to address what Definition of Done (DOD) and Definition of Ready (DOR), why they exist, and what some common pitfalls in their use are. 

Email address:

Leave this field empty if you're human:

What are Definition of Done and Definition of Ready?

DOR and DOD are agreements within the team. They can almost be considered as contracts that universally define some characteristics or requirements a story or task must fulfill before being considered ready for implementation or before being fully done. DOR addresses the former, DOD the latter.

They are essentially checklists that need to be, well…, checked before working on a story or before considering them as done. Both are always valid for all tasks and stories (as opposed to acceptance criteria that are valid only for the given story). They may change over time and some points within DOR and DOD might not be applicable for a specific task. As a default, however, they are valid and need to be satisfied.

Some examples for the Definition of Ready include: 

• Test cases are available 
• The story is estimated
• No unresolved dependencies to other teams

Definition of Done may be:

• All performance tests passed
• Documentation is updated
• Release notes shared with relevant stakeholders

There are many more.A team can include anything that they consider as important to be done before they start working on a story within DOR. The team can include anything that needs to be completed for a story to be considered done within DOD.

Why are Definition of Ready and Definition of Done needed?

There are many reasons why DOR and DOD are needed. Three stand out to me.

• Ensuring consistent quality
• Protecting the team
• Efficiency

Let me explain what I mean by those.

Ensuring consistent quality

The DOD often includes tests that need to pass or non-functional requirements that every product increment needs to meet. By including these the team ensures that a baseline of quality is always for every story before it is considered to be fully completed.

Frequently, these types of requirements in the DOD are uniform across the company or according to industry standards. This ensures that the product quality is consistent across the entire company or as expected by the market.

The Definition of Done also functions as a safety net. You may find that you are dealing with some specific requirements that are always valid but for some reason frequently overlooked. Adding them to the DOD ensures that they are not forgotten (as often). An example might be accounting for dark mode styling or documenting the work. 

In the end the DOD is a final quality gate that needs to be passed before releasing a new feature to production. Thus, it ensures a consistent quality baseline. Anything that the team thinks should be checked for all stories and tasks beforehand should be included.

Protecting the team

The Definition of Ready is somewhat similar to a contract between Product Owner, Stakeholders, and the team. Thus, the team has the right to demand that a task or story satisfies all points within the DOR before they will work on it. 

As such, it increases the barrier for adding – most of the times not completely clear – stories or tasks at the last minute or during the sprint.

Adding unclear stories or tasks at the last minute or during the sprint might be the single most frequent cause for chaos and frustration. It never ends well and should be avoided at all costs. If nothing else helps, the DOR is one effective tool to counter these “important” last minute requests from – sometimes powerful – stakeholders.

Efficiency 

Both the Definition of Ready and the Definition of Done ensure efficiency in the product development process. They affect different parts of the development process. The DOR leads to more efficient development work during the sprint and DOD means more efficiency in creating and refining stories.

A Definition of Ready should include all requirements that a story or task needs to fulfill in order to be implemented. In theory – and most of the time this is true in practice as well – satisfying all points within the DOR means less questions and uncertainties during the sprint. 

The team can simply implement without the need of having to align with the PO, other teams, or Stakeholders. Everything was already clarified upfront. Whenever there is a need to align, this is a source of inefficiency. Generally, developers then need to wait for an answer or for a meeting to discuss. During the wait time they work on something else. Afterward they return to focus on the original task. This context switching is mentally draining and inefficient. 

While the DOR increases efficiency in the actual implementation, the DOD increases efficiency by slimming down the process of writing and refining user stories or tasks.

First, PO and the team need to spend less energy trying to remember each and every story e.g. all the non-functional requirements. The ones that are always valid are already there in the definition of done.

Second, the requirements that are always valid do not need to always be written out for each story. This seems trivial. However, imagine having to write performance tests passed and documentation updated as acceptance criteria for every story. By itself that’s probably no more than ten seconds. However, if you need to do this for 1000 stories over a year it starts to add up.

Common pitfalls 

Using the Definition of Ready and Definition of Done is not terribly complicated. Nevertheless, there are a few common pitfalls I want to address.

As mentioned above, the DOR is essentially a contract that the team can demand to be fulfilled before they start working on something. This gives the dev team power to refuse work that is not ready. This sometimes leads to a dynamic where teams try to use the power the DOR gives them and refuse to touch anything that is not 1000% ready.

Usually this is a symptom of other problems. Thus, leadership and communication skills by Product Owner and Scrum Master are needed to make sure it doesn’t get to that. Always remember that Agile product development in the end is about being flexible. 

Speaking of flexibility, the DOR and DOD can change over time. I have found that teams tend to define them once and never review them. As always with all things in agile, it is important to regularly review the DOR and DOD and change them if need be.

DOR and DOD tend to become quite large. You might end up with a huge list of points that need to be checked. I have found that this often is a symptom of missing automation. This is a risk particularly for the DOD where more and more tests are added over time. In this case, it could make sense to automate all the tests and then only have something along the lines of test suite completed in the DOD instead of each test individually.

It often seems that the more mature a team becomes, the less focus is placed on DOR and DOD. I think this is not necessarily a problem. However, we should be conscious of this and not completely forget about the artifacts. Especially when new team members join, Definition of Ready and Definition of Done can be of great help.

Definition of Ready and Definition of Done work outside of agile and Scrum

The Definition of Done and Definition of Ready are important artifacts within agile product development processes. They are commonly used within the framework of Scrum. However, the underlying principles – that work packages need to be a certain way before they can be tackled and that there are certain things that need to always be done before the work is considered done – are universal principles that can be applied outside of the agile framework.

Therefore, I encourage you to evaluate whether it makes sense to implement something like DOR and DOD in any project you are working on. In case you are using Scrum and aren’t yet using DOR and DOD, I encourage you to try them out. You might be surprised at the powerful effects something this simple can have.

Coverphoto by Jo Szczepanska on Unsplash