In this article, I will explain Definition of Ready vs Definition of Done, their main differences, practical examples, and how I use both concepts in real projects.

I will also connect them to broader quality practices using the SAFe Framework as one of my references.

What Are Definition of Ready and Definition of Done?

I like to explain the difference with two very simple questions:

Definition of Ready asks: “Can we start?”

Definition of Done asks: “Can we honestly say we finished?”

The Definition of Ready protects the entrance of work into the development process.

The Definition of Done protects its exit.

When both are working properly, the team has a much clearer understanding of what must exist before work begins and what must be true before that work can be considered complete.

What Is the Definition of Ready (DoR)?

The Definition of Ready (DoR) describes the minimum conditions a task should meet before the team starts working on it.

It does not mean that every possible question must be answered before development begins.

Projects always contain uncertainty.

But there is a big difference between working with uncertainty and starting a task that nobody understands well enough.

Depending on the project, a Definition of Ready can help answer questions such as:

• Is the problem we are trying to solve clear?
• Is the objective of the task clear?
• Do we understand the expected outcome?
• Are the acceptance criteria documented?
• Have important dependencies been identified?
• Is enough technical information available?
• Are the main and alternative flows understood?
• Does the team have enough information to estimate the work?
• Have the most important questions been answered?

I use a very simple rule:

If the team still does not understand what needs to be done during refinement, the task probably is not Ready.

What Is the Definition of Done (DoD)?

The Definition of Done (DoD) establishes the conditions that must be satisfied before a task or delivery can truly be considered complete.

Its purpose is to avoid situations such as:

• Development is complete, but testing is not;
• Testing is complete, but approval is still missing;
• The feature works, but documentation has not been updated;
• The task is marked as Done on the board but still needs to return to the team.

All of these situations lead to the same question:

Is the work really Done?

Depending on the project, my Definition of Done may include:

• Acceptance criteria satisfied;
• Functional validation completed;
• Tests successfully executed;
• Automated tests passed;
• Technical review completed;
• Documentation updated;
• Technical and product standards followed;
• Formal acceptance completed when required.

The purpose is to give the entire team a reasonably objective understanding of what it means to say:

“We are done.”

Definition of Ready vs Definition of Done: What's the Difference?

For me, the difference between Definition of Ready and Definition of Done can be summarized like this:

Definition of Ready protects the beginning of the work.

Definition of Done protects its completion.

The DoR tries to prevent a task from starting before the necessary conditions exist to execute it properly.

The DoD tries to prevent a task from leaving the process before meeting the conditions the team considers necessary for a completed delivery.

When the Definition of Ready is weak, I normally expect to see:

• More questions during execution;
• More interruptions;
• More waiting time;
• Less reliable estimates;
• Higher risk of rework.

When the Definition of Done is weak, I expect a different set of problems:

• Tasks closed too early;
• Problems discovered after delivery;
• Reopened tasks;
• Inconsistent quality;
• Rework after what should have been completion.

Acceptance Criteria vs Definition of Done: What's the Difference?

Another common source of confusion is the difference between acceptance criteria and Definition of Done.

They are related, but they are not the same thing.

I separate the concepts this way:

• Definition of Ready: What must be true before this work can start?
• Acceptance criteria: What specific conditions must this particular delivery satisfy?
• Definition of Done: What must be true before we consider the work complete?

Acceptance criteria usually describe the expected behavior or outcome of a particular story, feature, or task.

The Definition of Done creates a broader quality standard that can be applied across many pieces of work.

For example, one feature may have an acceptance criterion saying that a customer must be able to reset a password by email.

The Definition of Done may additionally require that the feature has passed automated tests, received technical review, been documented, and met the team's quality standards.

Definition of Ready Example

In my projects, I often use a three-role model to create clarity and improve the initial documentation of a task:

• PO — defines the expected business outcome;
• UI — documents the expected and alternative user flows;
• Tech Leader — provides the main technical direction.

For a task to move toward Ready:

• UI documents the expected flow and relevant alternative flows;
• PO documents what is expected from the business perspective;
• Tech Leader provides the technical guidance required to build it.

Why do I use this model?

Because I do not assume that every person joining a project already has enough business, product, and technical knowledge to make every decision independently.

At the beginning, some professionals naturally become reference points.

Over time, the objective is for the rest of the team to gain enough knowledge and autonomy to depend less on them.

Refinement Is Also Part of My Definition of Ready

When a team discusses a task during refinement and important questions appear that nobody can answer, I do not simply push the task into the sprint.

Those questions are evidence that relevant information is still missing.

The task returns for clarification until we reach a reasonable level of understanding.

I am not looking for perfect documentation.

I am trying to remove predictable uncertainty before it becomes a blocker during execution.

Definition of Done Example

For the Definition of Done, I may also use the same business, design, and technical references to formally validate the delivery when necessary.

Testing becomes another important safety layer.

Depending on the project, a practical Definition of Done may include:

• Acceptance criteria satisfied;
• PO validation completed;
• UI validation completed when necessary;
• Peer review or technical review completed;
• Test cases executed;
• Automated unit tests passed;
• Documentation updated;
• Project standards followed.

The idea is to create a safety barrier.

If a critical condition has not been satisfied, the delivery should not be treated as complete.

Why Do Teams Abandon Definition of Ready and Definition of Done?

If DoR and DoD can provide so much clarity, why do teams abandon them?

I have a few hypotheses:

• Lack of experience from team leaders;
• Difficulty convincing others about the importance of these definitions;
• Lack of authority or influence over the team;
• Projects that are already behind schedule;
• Innovation-driven projects with greater uncertainty;
• Projects and products without clearly defined processes.

There is one behavior I see repeatedly.

When a project is late, we start removing things that appear to consume time.

We shorten refinement.

We start tasks before they are sufficiently clear.

We reduce validation.

The goal is to move faster.

But if these decisions create more questions, defects, and rework, we end up losing exactly the time we were trying to save.

When I suspect that the problem goes deeper than the process itself, I try to understand its root cause first. You can read more about this in How to Find the Root Cause of Your Project's Problems .

Before Changing DoR or DoD, Understand Who Needs to Be Involved

When the problem is lack of influence or authority, I would not simply impose a new Definition of Ready or Definition of Done on the team.

I would first align these definitions with the stakeholders who have the greatest influence and impact on the project.

I discuss this topic in more detail in: How to Use the Stakeholder Matrix to Gain Influence and Improve Project Communication .

Definition of Ready and Definition of Done Are Part of a Bigger Quality Discussion

For me, DoR and DoD are not isolated concepts.

They are part of a broader discussion about the quality of the process that transforms a need into a delivery.

This is why I like to connect them with some of the ideas behind SAFe Built-In Quality .

Shift Learning Left

Product development always includes scenarios that the team will only discover as work progresses.

The same is true for individual tasks.

But the later we discover an important question, dependency, or problem, the harder and more expensive it may become to correct it.

That can affect scope, quality, schedule, and cost.

For this reason, I try to move questions, validation, and learning earlier whenever possible.

Pair Programming and Peer Review

Pair programming and peer review can bring a second perspective into the construction of a delivery.

But there is an uncomfortable reality that I think is worth acknowledging:

If two people are working on one task, they are not working on two different tasks.

Quality has a cost.

And almost every project is under pressure to deliver faster.

These practices therefore need to be evaluated according to risk, context, and available capacity.

Collective Ownership and T-Shaped Skills

Another important objective is to avoid concentrating all critical knowledge in one person.

At the beginning of a project, or when new professionals join, their understanding of business rules, previous decisions, architecture, and delivery expectations may still be very limited.

That knowledge needs to be built and distributed progressively.

The goal is not for everyone to know everything.

The goal is to reduce dependencies that can become project risks.

Standards and the Definition of Done

Every professional develops patterns in the way they work.

When those patterns are shared and documented, they can become project standards.

This is directly connected to the Definition of Done.

If every person has a different interpretation of what a quality delivery means, the Done status quickly loses value.

This is also why I use test cases and automated unit tests as part of the Definition of Done in many projects.

If the tests fail, the product is not ready for my customer.

Workflow Automation

Workflows often contain manual handoffs between different professionals.

Every handoff can create waiting time.

Teams can also lose time manually inspecting tasks or looking for components that already exist.

Automating parts of this process can help reduce manual work, waiting time, and cost.

DoR and DoD Also Affect Productivity and Predictability

When a task starts without enough clarity, the lost time does not disappear.

It reappears during execution as:

• Questions;
• Messages;
• Meetings;
• Waiting;
• Rework;
• New estimates;
• Delays.

Likewise, when a task is considered Done too early, part of that work often comes back later as correction or rework.

That is why I do not see Definition of Ready and Definition of Done only as quality controls.

They also help protect project flow, productivity, and predictability.

How Saint Jude Helps Identify Ready and Done Problems

Jira, Azure DevOps, ClickUp, Monday.com, Asana, and other project platforms contain a large amount of information about tasks and how work moves through a project.

Saint Jude works as a Project Intelligence layer over this data.

The objective is to help project managers, PMOs, and delivery leaders identify signals such as:

• Tasks entering execution without enough information;
• Estimates that do not match actual execution;
• Work remaining too long in specific workflow states;
• Recurring blockers;
• Tasks being reopened or returned for correction;
• Recurring rework;
• Delays that may affect the project schedule;
• Quality problems affecting cost and productivity.

The purpose is not to turn Definition of Ready and Definition of Done into bureaucracy.

It is to understand whether the rules created by the team are actually helping work flow better or whether the same problems keep happening.

Definition of Ready and Definition of Done Should Not Exist Only in Documentation

Creating a DoR and a DoD solves nothing if they become two forgotten checklists on a documentation page.

They need to be part of how the team actually works.

The Definition of Ready should help prevent work without the minimum necessary clarity from entering execution.

The Definition of Done should prevent incomplete work from being treated as complete.

And both should evolve as the team learns.

Definition of Ready tells us when we can start. Definition of Done tells us when we can honestly say we have finished.

If you want to understand where unclear tasks, rework, blockers, and quality problems are affecting schedule, productivity, or cost, take a look at Saint Jude and its Project Intelligence modules .

And in your team? Are Definition of Ready and Definition of Done really part of the process, or do they only appear when someone remembers they exist?

See you soon!

Erik Scaranello