Ready vs Done: The Underrated Process That Keeps Work Clean
In modern software teams, clarity on when a task truly starts and when it is truly finished is critical. Enter the Definition of Ready (DoR) and Definition of Done (DoD) — two team-defined checklists that mark the boundaries of a task’s life.
Definition of Ready (DoR) is the agreed checklist of conditions that must be met before a task is considered “ready” to begin. It ensures task readiness: that the team has all the context and inputs needed to start implementation. Definition of Done (DoD) is the counterpart at the other end — a checklist of criteria that a task must meet to be considered truly “done.” It defines task completeness: the quality checks, approvals, and deliverables required before the task can be closed out. In short, DoR tells us when work can start, and DoD tells us when work can finish. One guards against starting work too early; the other prevents declaring work done too soon.
If you’ve been following this Processes That Work series, you’ll recall our previous discussion in Writing Engineering Tasks as a Team Process on crafting clear tasks. Now we expand into the criteria for starting and finishing those tasks.
DoR vs. DoD — Knowing When to Start and Stop
It’s easy to confuse DoR and DoD because they’re both about setting criteria, but they serve opposite ends of the process. The DoR is typically used during backlog refinement and sprint planning to decide if a user story or ticket is sufficiently prepared to be pulled into active work. If an item meets the DoR (e.g. has clear requirements, context, and scope), the team can confidently commit to it. The DoD, on the other hand, is applied during development and especially at the end of the task to ensure all the required work for sign-off is completed. A story meeting the DoD means it isn’t just coded, but also tested, reviewed, documented, and accepted — in other words, it’s potentially shippable.
Notably, the DoD is an official Scrum commitment for any Increment, whereas the DoR isn’t explicitly in the Scrum Guide (teams adopt it as an extra guardrail). But both are powerful as team agreements. The DoD defines the quality bar and completeness standard for all work, and the DoR defines the minimum state of readiness before work begins. Used together, they create a controlled “gateway” at the start and end of each task. This keeps the development process stable and predictable — no work enters the pipeline half-baked, and nothing leaves it half-done.
Why You Need Both Definitions
Having both a Definition of Ready and Definition of Done helps a team maintain a healthy development flow. A clear DoR prevents work from starting too early — before the team has enough information or resources. Without it, teams may pull in vaguely defined tasks or user stories lacking context, which leads to confusion, thrashing, and delays once implementation has begun. In contrast, a clear DoD prevents work from being closed prematurely — before it’s truly completed to a satisfactory level of quality. Without it, teams might mark a task “done” when in reality it still needs bug fixes, additional testing, or clarification, resulting in rework later.
Think of DoR and DoD as filters. The DoR filter at the front of the process ensures only well-prepared tasks enter a sprint. The DoD filter at the back ensures only fully finished tasks exit the sprint as completed increments. This one-two punch significantly reduces the risk of both false starts and false finishes. It improves communication and efficiency: the team spends less time during the sprint chasing missing information or dealing with unforeseen scope changes, and stakeholders aren’t surprised by deliverables that don’t meet expectations. In fact, teams that establish a solid DoD find they avoid the common mistake of thinking something is done when it’s not truly releasable.
By defining “ready” and “done” explicitly, you set shared expectations. The team knows when an item is properly ready for development, and everyone understands what done means for task completeness. This shared understanding means fewer misunderstandings and far less back-and-forth. One Scrum Alliance review put it succinctly: by having both DoR and DoD in place, teams improve their efficiency and effectiveness, working collaboratively toward their goals. In short, DoR and DoD together keep the development cycle healthy — work comes in prepared, and goes out verified.
The Cost of Missing DoR or DoD
What happens when a team lacks these definitions? Let’s look at two common (and painful) scenarios:
Without a Definition of Ready: Unprepared Work and Delays
Without a clear DoR, teams often start work on tasks that aren’t actually ready. For example, imagine a developer picks up a Jira ticket for “Add search functionality” as soon as it appears on the sprint backlog, only to discover mid-implementation that there’s missing input: no defined acceptance criteria for search results relevance, unclear UI design, and undiscovered dependency on an API endpoint. The team scrambles to get answers during the sprint. This unprepared start can lead to chaos — scope changes or blockers emerge late, development stalls, and the team may even have to drop the story and return it to the backlog. Sprint commitments suffer.
This isn’t just a hypothetical — teams regularly face surprises when they pull in work that hasn’t been refined. Adding Product Backlog Items to a sprint when they are not ready will create unnecessary impediments to delivering a valuable increment. In practice, you’ll see developers saying “we can’t finish this because we discovered X” far too often. Symptoms of a missing or weak DoR include team members “scrambling to understand work within the sprint,” or not completing all their sprint stories because requirements were ill-defined. In short, without a DoR the team ends up doing just-in-time analysis (or design) in the middle of implementation, which is stressful and inefficient.
Without a Definition of Done: “Done” That Isn’t Done
Now consider a team that doesn’t have a shared Definition of Done. One developer says “code complete, moving on” after writing a feature — but they didn’t run all the tests, and no one reviewed the code. QA finds bugs a day later, documentation for the feature is missing, and the product owner wasn’t aware the feature was “done” to even verify it. The result is that the work claimed as done keeps bouncing back for rework, patching, or more verification. Essentially, the task was closed too early and lingers like a ghost that isn’t laid to rest.
Without a solid DoD, teams may release features that don’t meet quality standards, stakeholders might get incomplete or buggy deliverables, and time gets wasted on rework due to unclear expectations. An incomplete “done” is a classic source of technical debt and customer dissatisfaction. For instance, a feature might be functionally complete from a coder’s perspective but not shippable — perhaps it lacks error handling, hasn’t been security tested, or fails in certain browsers. A robust DoD acts as a safeguard against this by listing all those necessary completion steps (testing, review, etc.) that ensure the work is truly finished. Without it, the team’s definition of “done” is inconsistent — each developer might have a different idea of completeness — leading to gaps. This ambiguity ultimately means more defects and iterations after you thought a task was closed.
Bottom line: Missing a DoR means you risk starting work on the wrong foot (with incomplete info), and missing a DoD means you risk leaving work half-baked. Both situations lead to waste and frustration.
What Goes Into a Definition of Ready?
How do you know a task has enough readiness for development? Teams capture this in their Definition of Ready checklist. While specifics vary, a good DoR typically ensures that a backlog item provides sufficient clarity and feasibility for the team. Here are common criteria in a DoR:
- Clear Description & Context: The task (user story or issue) is written clearly and with context. Everyone understands what is being asked and why. Any background information or user context needed is provided (e.g. personas, use case scenarios).
- Explicit Acceptance Criteria: The story has testable acceptance criteria defined. These are the conditions that the product owner or stakeholders will use to confirm the story’s functionality. Clear acceptance criteria mean the team can determine “how do we know when we are done?” for this specific item.
- Dependencies Identified (and No Blockers): Any external dependencies, integrations or prerequisites are known and either resolved or planned. If the task relies on another team’s work, an API, or design asset, those are addressed or scheduled. There are no blockers that would prevent the team from completing the item in the upcoming sprint.
- Estimated and Right-Sized: The team has estimated the effort (e.g. in story points or hours), and it’s small enough to fit within a sprint. A rule of thumb is that the item follows the INVEST criteria — it’s Independent, Negotiable, Valuable, Estimable, Small, and Testable. If an item is too large or vague to estimate, it’s not ready.
- Team Buy-In: The team members agree the story is understood and ready to work on. Often this means the Product Owner and team have discussed it in refinement and everyone is on the same page regarding the goal and scope. In some teams, this includes having stakeholder sign-off on the requirements — e.g. the Product Owner has approved the story to enter development.
- Acceptance of “Ready” by Assignee: In practice, when pulling the task into a sprint, the owner (the developer or pair who will work it) confidently accepts it. The task is assigned to someone who acknowledges it’s clear enough to start. If no one feels it’s clear, it might not be ready yet.
A concise example of a Definition of Ready might read like: “Story has a clear user narrative, defined acceptance tests, all designs attached, no unresolved blockers, and an estimate agreed by the team.” Only once a story meets these readiness criteria will the team move it from the backlog into the active sprint. This discipline saves the team from avoidable mid-sprint surprises. It also forces necessary conversations to happen upfront (better in planning than during crunch time!).
What Goes Into a Definition of Done?
The Definition of Done is all about quality and completeness. It’s a checklist the team must satisfy to call any task “done done” (meaning truly completed). A strong DoD sets a high bar, covering code quality, testing, documentation, and approval. Common elements include:
- Code Completed and Merged: The code changes for the task are fully implemented and merged into the main codebase (e.g. the
mainordevelopbranch). This implies code is not sitting on a developer’s local machine or a long-lived feature branch; it’s integrated with the latest code. - Peer Review Conducted: The code has been peer-reviewed (e.g. via a pull request) by at least one other team member and any requested changes are addressed. Code review ensures standards are met and catches issues early.
- Automated Tests Passed: The feature or fix is covered by automated tests (unit tests, integration tests as appropriate) and all tests are passing in the continuous integration pipeline. This gives confidence that new code works and hasn’t broken existing functionality (regressions).
- Feature Verified by QA: Beyond developer-written tests, the feature has been tested in a staging or test environment by QA or the team, and no critical bugs remain open. If any lower-severity issues are deferred, it’s done with explicit sign-off (acknowledgement) from the Product Owner or stakeholder that they’re okay to postpone that fix.
- Meets Acceptance Criteria: All the acceptance criteria defined for the story have been met and verified. For each expected behavior or outcome, the implementation satisfies it (often confirmed by the Product Owner during story acceptance).
- Documentation Updated: Relevant documentation is updated to reflect the changes. This might include user documentation, API docs, architecture diagrams, or even updating the README and release notes. Future maintainers or users shouldn’t be left guessing.
- Deployed to a Demo/Staging Environment: The new functionality is deployed to an environment where it can be demonstrated or tested end-to-end (often part of meeting acceptance criteria). This ensures deployment considerations are handled and we know it works outside a dev’s machine.
- Product Owner Approval (Demoed): The completed work has been demonstrated to the Product Owner or relevant stakeholder, and they have accepted it as done. This is essentially the final sign-off that the feature meets the need. In Scrum, this often happens in the Sprint Review for each story — if it doesn’t meet expectations, it’s not accepted as “done.”
In essence, a story that satisfies the DoD is in a potentially shippable state. It means if we needed to release it to users, we could — it’s fully tested, no major issues outstanding, and all supporting work (like docs) is completed. By enforcing a comprehensive DoD, the team ensures consistent quality across all tasks. It also prevents the accumulation of “almost done” work (which turns into future headaches).
To illustrate, here’s a quick contrast of Definition of Ready vs Definition of Done criteria side by side:
In practice, your team’s lists may vary, but they should capture these fundamentals of readiness vs completeness.
Defining DoR and DoD Collaboratively (Start Simple!)
How do you create these definitions? The key is to make them team-level agreements. A manager can’t just decree the DoD or DoR — they have to be shaped and owned by the whole team for everyone to buy in. Typically, the Scrum Master (or team lead) will facilitate a session to brainstorm what the team needs before starting a task (DoR) and what quality checks to require for done (DoD). Include developers, QA, the Product Owner, and any other stakeholders in this discussion. This collaboration ensures the checklists cover all perspectives. For example, the Product Owner might insist that user documentation updates be on the DoD, while developers might add that “performance tests passed” should be included for certain components. By getting input from all roles, you create a well-rounded list that everyone agrees to honor.
Start small and simple. Especially if your team is new to this, don’t go overboard writing a 20-point checklist on day one. It’s wise to start with a few critical items and let the definitions evolve. Start with small [definitions] and improve iteratively, reviewing your DoR and DoD regularly (for example, at each sprint retrospective). Early on, new teams sometimes create an overly exhaustive DoR (trying to anticipate every detail before starting) and a very basic DoD. With experience, you’ll find the balance: you might trim the DoR once the team learns to handle some uncertainty, and expand the DoD as the team commits to higher quality standards. The definitions are living documents. If they aren’t working — say, the DoR is too lax and you keep running into surprises, or the DoD is unrealistic and causing delays — the team can and should revise them. Use retrospectives to discuss these pain points and update the criteria accordingly.
Crucially, everyone on the team must understand and agree to these criteria. They represent a shared commitment. This also means everyone is empowered to say “Hey, this story doesn’t meet our DoR yet, let’s not start it” or “We can’t call this done until it meets our DoD — there’s an acceptance test failing.” This peer accountability is healthy. It ensures the DoR/DoD are more than just a poster on the wall — they become part of the team’s day-to-day working process. The Definitions should be visible (many teams put them on the wiki or even in the project management tool for easy reference) and revisited whenever something changes in how the team works.
Using DoR and DoD in Practice: Planning, Review, and Reducing Rework
Having well-defined DoR and DoD criteria makes several Scrum ceremonies and team processes run smoother:
- Sprint Planning: When planning a sprint, the team can confidently pull items from the backlog that meet the DoR, knowing they won’t be biting off ambiguous work. The DoR acts as a gate — if a story is missing key details, the team should postpone it rather than force it into the sprint. This leads to more predictable sprint outcomes. Teams use the DoR during sprint planning to decide if a PBI (Product Backlog Item) should be added to the sprint, because adding items that aren’t ready can create avoidable impediments. In practice, teams might quickly checklist each top candidate story: “Do we have everything? Is it ‘ready’?” — only ready items get selected. This means less thrash during the sprint and higher likelihood that the team completes what they commit to. Essentially, DoR is a planning tool to ensure the team isn’t planning work that will blow up later.
- During Development: The awareness of DoD criteria influences how developers work within the sprint. Knowing the definition of done upfront reminds everyone that writing code is not enough — they will also need to write tests, update docs, get reviews, etc. Teams often break down tasks in the sprint to include these subtasks (e.g. “code”, “write tests”, “update documentation”, “QA review”). This mindset, driven by the DoD, helps reduce rework. Instead of rushing to declare something done and then revisiting it when bugs or omissions are found, the team proactively includes quality steps. It’s much cheaper and easier to catch issues as part of the task’s workflow than after it’s been marked complete. By making the DoD part of the development workflow (often as an acceptance checklist on the ticket), teams catch more issues before the code is merged, significantly cutting down on rework and unplanned work later.
- Sprint Review / QA Sign-off: When it comes time to review what’s been built (in a Sprint Review or demo to stakeholders), a solid DoD ensures there are no nasty surprises. Only tasks that meet the DoD are considered “done” and ready to demo. This means features presented to stakeholders are truly complete: they work as expected, meet the acceptance criteria, and have all supporting artifacts. The Scrum Guide even specifies that if an item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review — it should return to the backlog. Following this principle keeps the review focused on incremental value that is actually shippable. Stakeholders develop trust that “done means done.” They won’t be handed half-cooked features, and the team’s credibility improves. Moreover, the DoD provides transparency in the review: the team can say, “This feature meets our DoD, so it’s fully completed and ready for release”, which sets clear expectations.
Implementing DoR/DoD can even be facilitated by tools. For instance, some teams use custom fields or checklist plugins in Jira/Linear to track readiness and done criteria on each story. But tool or no tool, the real power is in the team’s adherence to these agreements. Over time, you’ll likely find that having a Definition of Ready and Done significantly reduces rework and defects, because issues are caught either before work starts or before work is declared finished. You’ll spend less time “going back to fix” or clarifying things after the fact, which is a huge efficiency boost. One study of agile teams noted that a clear DoD helps avoid ambiguity and ensure high-quality work, meaning less time wasted on corrections. Similarly, a clear DoR enhances upfront communication and prevents false starts, so the team isn’t constantly context-switching to gather missing info mid-sprint.
Conclusion and Next Steps
The Definition of Ready and Definition of Done serve as the two guardrails of every task. By establishing what “ready” means, your team ensures that work begins with clear purpose and context. By defining “done,” your team ensures that work ends with verified quality and completeness. Together, they squeeze out the uncertainty in the middle, leading to a smoother, more predictable development process. Teams that rigorously apply DoR and DoD find that they can plan better, deliver more consistently, and maintain higher quality with less last-minute chaos. It’s about setting the boundaries of a task so everyone knows exactly when a ticket enters the coding stage and exactly when it can be closed and considered shippable.
Going forward, an important element in making DoR and DoD successful is clear ownership and responsibility. Who makes sure an item meets the DoR before pulling it in? Who ensures each DoD box is checked before closure? In our next article we’ll dive into how teams assign and manage responsibility throughout the lifecycle of a task — from refinement to sign-off. Don’t miss it if you want to learn how to keep your process running like a well-oiled machine with the right people accountable at each step.
If you found this article useful, please give it a clap to show your support. Follow our publication for more insights in the “Processes That Work” series, and share this piece with your team — it might spark a conversation about improving your own DoR/DoD definitions!
