Definition of Done & Ready: What They Are and Why They Matter

TL;DR — Definition of Done & Ready in 60 Seconds

• Definition of Ready (DoR): A team agreement on what must be true before work can start—clear requirements, designs linked, acceptance criteria defined
• Definition of Done (DoD): A team agreement on what must be true before work is complete—code reviewed, tests passing, deployed to staging
• Key insight: These aren't gatekeepers or bureaucracy—they're sanity checks that prevent blocked sprints
• Who owns them: The entire team defines and iterates on both agreements together

Definition of Ready (DoR) and Definition of Done (DoD) are team working agreements that answer two critical questions: "When is work ready to start?" and "When is work actually finished?" Without clear answers to these questions, teams waste time on blocked tickets, rework incomplete features, and constantly debate what "done" really means.

"Definition of Ready and Done aren't about frameworks—they're sanity checks."

As a Product Manager, I've learned that execution isn't the only thing to consider. Having clear working agreements between Product and Engineering is fundamental for alignment and acceleration. This article covers how to create and use both definitions effectively, with real examples from my experience working with agile teams.

Why Teams Need These Agreements

On multiple occasions, I made the mistake of skipping parts of the planning process to "be faster" by:

• Thinking big technical open questions will be answered during a sprint
• Assuming the design for tickets will be finished in XYZ days
• Promising to get unblocked by other teams without having their commitment

This also happens from the Engineering side:

• Creating and pulling tech stories without clear acceptance criteria
• Pulling unestimated tickets because "everyone knows what to do"
• Not breaking down bigger chunks of work because "it takes no longer than 1-2 days..."

When things aren't clear, people make "faster" decisions under pressure rather than spending time to gain clarity. If someone gets sick who can answer a question or deliver a design, you won't be able to finish the work. The DoR and DoD help hold each other accountable for responsibilities and prevent these common sprint planning mistakes.

What is the Definition of Ready?

The Definition of Ready (DoR) is a working agreement within a development team. It defines clear actions and criteria that need to be fulfilled before pulling user stories into a sprint. The DoR can be applied to Scrum or Kanban teams.

Some teams define separate DoR criteria for sprints. I believe that if all tickets are regularly groomed and set to "ready," the sprint should be ready by itself. However, there is no wrong or right—what's most important is what you agree on internally.

The DoR should be defined and owned by the whole team and regularly refined during retrospectives. It can be a simple Google Doc, Confluence page, or even a flip chart entry. The DoR is closely tied to your backlog refinement process—checking DoR criteria during grooming sessions helps catch gaps early.

What a Definition of Ready Isn't

A Definition of Ready is not a loose commitment written in a document that nobody cares about. It's not a top-down decision made by an engineering or product manager either. The idea of a DoR isn't to slow down processes with bureaucracy. The aim is to define a standard for product requirements to ensure efficient and seamless development.

Real-World Definition of Ready Example

Here is an example from one of my teams. The goal of our DoR is to make sure that features/stories/tasks are defined enough to start and finish development within the sprint commitment:

• User stories/tasks/enablers and spikes have an understandable title (at least half-sentences / full sentences)
  • The title should be a short description of the goal, understandable to people with domain knowledge (e.g., "Create idx_product_usr" is a bad title. A good one: "Create indexes for user/product queries")
• Product backlog items (PBIs) have an understandable introduction and acceptance criteria following the INVEST scheme
• UI involvements or design tasks require the design to be linked to the ticket/story or epic
  • The ticket lists all new image assets that must be added
  • If assets aren't final yet, dimensions and constraints must be agreed upon beforehand
• PBIs have been groomed with the team, estimated, and prioritized by the product owner/manager

Based on your agile processes and workflows, you can add more or less information to your DoR. What's most important is to get started and create a document.

Attention: It's important to not overcomplicate the application of the DoR. I've seen teams use it as a gatekeeper to block anything from entering a sprint that doesn't cover 100% of the DoR. Sometimes it's not possible to get all information upfront, or it's clear you'll get an answer right after the sprint starts. The DoR is a tool that should help prepare work better—not just a bureaucratic process.

The first point of the Agile Manifesto says: Individuals and interactions over processes and tools. Using the DoR as a tool is great as long as you don't ignore the interaction with individuals.

What is the Definition of Done?

While the DoR focuses on getting things ready, the Definition of Done (DoD) focuses on the final stage: getting work done.

"Both require a lot of discipline. People underestimate how hard both frameworks are."

The DoD is important for all team members—not only Product Managers but also Engineers, Product Designers, and QA. Like the DoR, it can be applied to every framework you work with. The whole team defines and owns it and regularly iterates on it.

"Done" can be defined on multiple levels:

• Story level (when is a story or ticket done)
• Release level (when is a release done)
• Feature level (when is a feature done)
• Sprint level (achieving the sprint goal)

What a Definition of Done Isn't

The Definition of Done isn't an agreement that any team member can ignore. The DoD isn't vaguely formulated, leaving room for interpretation. Instead, the DoD defines clear criteria that must be met to consider a feature or product as "done." Common requirements include code review by another engineer, testing by QA, and approval by the Product Manager.

Real-World Definition of Done Example

To start defining a DoD, I recommend beginning at the story/ticket level. In my current team, we started with simple things like:

• The code has been reviewed (4 eyes principle)
• All acceptance criteria have been fulfilled
• All automated tests are passing (integration/unit tests, etc.)
• The story has been deployed to [Stage] (can be "production" or another environment depending on your release cycle)
• The web application has been tested on: [Browser], [Version], and more...
• The story has been reviewed by the Product Manager (and Product Designer if needed)

Does the Product Manager need to review every single ticket? I review mainly end-to-end stories that are customer-facing or tickets that have a bigger impact on the live system. Technical improvements won't always be reviewed by me. This depends on your role, domain, and agreement within your team. Technical Product Managers should review technical stories as well.

In my experience, teams tend to do well with one clear DoD. If you and your team have clarity on what "done" means at the ticket level, you can easily apply it to sprints, releases, or features. If not, review and enhance the existing DoD or create additional level-specific ones.

Common Mistakes with DoR and DoD

Here are the most common mistakes I've seen teams make with these agreements:

• Using them as gatekeepers: The DoR and DoD should enable work, not block it. If 90% of criteria are met and the remaining 10% will be resolved in a day, don't block the ticket.
• Set and forget: Both agreements should evolve with your team. Review them during retrospectives when you notice recurring issues.
• Top-down imposition: These must be team agreements. A DoD imposed by management without team input will be ignored.
• Too complex: Start simple. A DoR with 20 checkboxes is harder to follow than one with 5 essential criteria.
• No accountability: If criteria aren't checked, the agreements become meaningless. Build DoR/DoD review into your workflow.

Benefits of Working Agreements for Product Managers

Working agreements help you better prepare your projects. Especially at the beginning of a career, the DoR can help make sure all relevant information for a ticket and sprint is covered. Well-prepared stories and backlogs are a foundation for smoother sprints, which can lead to better sprint achievements. This helps with planning certainty and communicating clear project updates to stakeholders.

With good planning and a clear definition of when things are done, you're way better set than I was a couple of years ago. Start by defining one simple DoR and DoD with your team—you can always iterate and improve them over time.