Module 4 · The test process (STLC)

Definition of Ready and Definition of Done

By the Mutqan Soft QA team · · 19 min · Beginner

The Definition of Done (DoD) is a team’s shared list of the quality measures every piece of work must meet before it counts as finished. The 2020 Scrum Guide calls it a formal description of the state of the Increment when it meets the quality measures required for the product. If the DoD says "code reviewed, acceptance criteria covered by passing pipeline tests, no open Blocker or Critical defects", a story that works on the developer’s laptop but has one failing test is not done, whatever the task board says.

The Definition of Ready (DoR) applies the same idea at the start: a short checklist a backlog item should meet before the team takes it into a sprint. It is not part of the Scrum Guide but a practice many teams add. ISTQB CTFL v4.0 treats the two as the agile names for exit and entry criteria, the subject of the previous lesson.

Why it matters

Without a shared definition, "done" means "merged" to the developer, "usable by customers" to the product owner and "checked on the agreed browsers in both languages" to the tester. Work looks finished while it hides undone work — missing tests, unreviewed code, untranslated messages — that surfaces at release as a pile of defects. A DoD sets the same bar for every item, so the progress shown at a Sprint Review is real.

The DoR addresses the opposite cost: stories that enter a sprint with unclear rules or a blocked dependency, so the tester finds the gaps mid-sprint, when questions cost the most. Together they turn "please test this properly" into agreed, checkable criteria that the whole team owns.

The Definition of Done in the Scrum Guide

As the lesson Scrum for Testers showed, the DoD is the commitment for the Increment: an item that does not meet it is neither released nor presented at the Sprint Review. Two more points from the 2020 Scrum Guide matter when you write one. Teams working on the same product share one DoD. And the Guide does not list its contents; they are the team’s decision, so testers should help write them.

  • It applies to every item. Rules for one particular story are that story’s acceptance criteria.
  • It is binary: an item meets every criterion or it is not done. There is no "almost done".

Quality criteria that belong in a DoD

A good criterion is checkable — anyone can answer yes or no and point to evidence — and achievable inside the sprint. "Tested" is not checkable; "every acceptance criterion is covered by a test that passes in the CI pipeline" is. Include non-functional quality as well; the characteristics of ISO/IEC 25010 are a useful prompt list. The sample DoD in the lesson Scrum for Testers is a good start. Extended with code review, accessibility and a security scan, and with its other items made more precise, it might read:

  • Code reviewed by another developer and merged to the main branch.
  • Every acceptance criterion covered by a test; automated tests pass in the CI pipeline.
  • Regression suite passes on the main branch.
  • No open Blocker or Critical defects for the item; other defects logged in the Product Backlog.
  • New or changed screens checked for accessibility: every control works with the keyboard alone and has a name a screen reader can announce; error messages are clear.
  • Screens checked in Arabic and English on a phone and a desktop browser.
  • No new high-severity findings in the security scan.

Try it: Acceptance Criteria Generator

The Definition of Ready: a team practice

The Scrum Guide has no Definition of Ready. It says only that items the team can make Done within one sprint are deemed ready for selection in Sprint Planning, usually after refinement. A DoR writes that expectation down as a short checklist used in refinement.

Treat it as a conversation aid, not a contract. A DoR that demands every detail up front turns each sprint into a small waterfall, so many teams still take a nearly ready item when the open question can be settled early in the sprint. Typical items:

  • The story says who needs what and why.
  • Acceptance criteria are written and reviewed for testability by a developer and a tester.
  • Dependencies such as another team’s API or translations are known and available.
  • Designs are attached for interface changes, including the right-to-left layout.
  • Test data needs are known, and the item fits in one sprint; if not, it is split.

Try it: User Story → Test Scenarios

How DoR and DoD relate to entry and exit criteria

ISTQB CTFL v4.0 notes that in agile development exit criteria are often called the Definition of Done, the team’s objective measures for a releasable item, and that the entry criteria a user story must meet before development and testing start are called the Definition of Ready. The mapping is close, but three differences matter:

  • Scope: exit criteria in a test plan are usually set per test level or release; a DoD is a standing agreement for every item in every sprint.
  • Content and ownership: a DoD also covers code review, documentation and deployment, and it belongs to the whole Scrum Team rather than to a test manager.
  • Levels: some teams keep a separate release checklist (full regression, performance test) for checks that do not fit every sprint. It works as release exit criteria; anything still open on it is undone work, and the retrospective is the place to move such checks into the DoD.
DoR vs DoD: the Definition of Ready is a team practice checked in refinement before Sprint Planning; the Definition of Done is the Scrum Guide commitment every item meets before it joins the Increment.

Definition of ReadyDoR

Can the team start this item without guessing?

Source:
Team practice; not in the 2020 Scrum Guide
Checked:
In refinement, before Sprint Planning selects the item
Applies to:
Each Product Backlog item before selection
Name in ISTQB CTFL v4.0:
Entry criteria for a user story
If not met:
Refine or split it; it waits in the Product Backlog
Typical tester criteria:
Testable acceptance criteria, known test data, available dependencies

Definition of DoneDoD

Is this item finished, with no hidden work left?

Source:
The 2020 Scrum Guide: the commitment for the Increment
Checked:
Before the item is presented at the Sprint Review or released
Applies to:
Every item and the Increment as a whole
Name in ISTQB CTFL v4.0:
Exit criteria for a releasable item
If not met:
Not presented or released; returns to the Product Backlog
Typical tester criteria:
Tests pass in CI, regression suite passes, no open Blocker or Critical defects

Worked example: one story from ready to done

Story: "As a returning customer, I want to save up to five delivery addresses so that checkout is faster." In refinement the tester checks it against the DoR, and two items are not met: nothing says what happens with a sixth address, and another team’s address-validation API arrives only next sprint. The team adds a criterion ("a sixth address is rejected with a message stating the limit of five"), and the product owner moves validation into a separate story. Now the story is ready for Sprint Planning.

Before the Sprint Review the team checks the DoD and links the evidence to the story:

  • Review, acceptance tests (fifth address saved, sixth rejected), regression suite, Arabic and English screens on phone and desktop, security scan: met.
  • Defects: the exploratory session found one Minor defect, logged in the backlog; no Blocker or Critical defect is open: met.
  • Accessibility check: not met — the "Delete" icon button can be reached with the keyboard, but it has no accessible name, the text assistive technology reads out for a control, so a screen reader announces only "button".
  • Result: the story is not done. The developer adds the name and the tester checks it again the same day (confirmation testing). Left unfixed, the story would not be shown at the Sprint Review and would return to the Product Backlog — never reported as "done except accessibility".

Try it: Requirements → Test Cases

Common mistakes

  • Treating the DoD as the tester’s sign-off list. It is the whole team’s commitment, and the testing it requires happens inside the sprint.
  • Writing criteria nobody can check, such as "tested" or "no bugs". Testing shows the presence of defects, not their absence: "no open Critical defects" can be confirmed, "no bugs" cannot.
  • Confusing acceptance criteria with the DoD, or assuming that meeting a story’s acceptance criteria alone makes it done.
  • Reporting "done except testing" or moving checks into a later "testing sprint", which hides undone work until release.
  • Turning the DoR into a rigid gate, or presenting it as part of Scrum.
  • Never revisiting the DoD, so the same kind of defect escapes sprint after sprint.

The QA perspective

In refinement the tester is often the first to see that a story is not ready: missing negative cases, untestable wording, unknown test data. Ask there, and when a gap keeps recurring, propose a DoR item that catches it. In Sprint Planning check that test design, automation and exploratory sessions are planned as sprint tasks, or the DoD cannot be met in time.

Link the evidence for each DoD criterion from the story: the pipeline run, the session notes, the accessibility check. When a defect escapes, bring a concrete proposal to the retrospective, such as "forms are checked with the keyboard only". And if someone wants to call an item done while a criterion is not met, make it visible: changing the DoD is an open team decision, never a silent exception for one story.

Practice exercise

Rewrite a weak DoD and check a story for readiness

Your task

A clinic booking team’s Definition of Done reads: "Code complete. Tested. No bugs. Product owner happy. Documentation updated if needed." Rewrite it as checkable criteria, including at least two non-functional concerns.

Then write a short DoR and check this story against it: "As a patient, I want to upload a photo of my insurance card before my visit so that check-in at the clinic is faster." Note what is not met and the questions you would ask in refinement.

Steps
  1. Ask of each DoD line: can anyone answer yes or no with evidence? Rewrite it or drop it.
  2. Add criteria for the missing quality concerns.
  3. Write the DoR and check the story against it.
  4. List your questions for the product owner.
Show the model answer
Model answer

Why the lines fail: "Code complete" and "Tested" cannot be checked, "No bugs" can never be confirmed by testing, "Product owner happy" is a feeling, and "if needed" leaves open who decides.

Rewritten DoD: code reviewed and merged; every acceptance criterion covered by a test that passes in CI; regression suite passes; no open Blocker or Critical defects; new screens checked with the keyboard only and for clear error messages; screens checked in Arabic and English on phone and desktop; help text updated when user-visible behaviour changes. The keyboard check and the language-and-device check are the two non-functional criteria.

DoR: value stated; acceptance criteria written and reviewed; dependencies available; designs attached; test data known; fits in one sprint. Only the value is met. The story has no acceptance criteria; its dependencies are unknown (is the card checked with the insurer, and is that service available?); there is no design for the upload screen; and the test data is unclear: you need images of different file types and sizes, a blurred photo and an expired card, all synthetic, because real insurance cards are personal data. Until the insurer check is settled nobody knows whether the story fits in one sprint; it may be split into the upload now and the verification later.

Questions: Which file types and what maximum size are accepted? Is the card checked with the insurer, and what does the patient see if it is expired or rejected? Who may view the image, and how long is it kept? Can the patient replace or delete it? What happens if the upload fails halfway?

Frequently asked questions

How is a Definition of Ready different from the entry criteria in a test plan?

Both state what must be true before work starts (ISTQB CTFL v4.0 calls the DoR the entry criteria for a user story), but they differ in scope and timing. Entry criteria in a test plan are usually set for a test level or activity and checked once before it starts, for example "the test environment is available and the smoke tests pass". A DoR is checked for each backlog item in refinement and asks whether that item is understood well enough to build and test. A team can use both: a DoR for its stories and entry criteria for, say, acceptance testing by a customer.

How can a team check the DoD on every item without slowing down?

Let the pipeline check what it can: the tests for the acceptance criteria, the regression suite and the security scan run on every change, and their results are linked from the story. Keep the checks a person must do, such as the keyboard check and the two-language check, small, and plan them as sprint tasks. Automated accessibility checkers find only some problems, such as a missing accessible name, so they support the keyboard check rather than replace it.

Who decides what goes into the Definition of Done?

If the organisation sets a DoD as a standard, every team follows it as a minimum. Otherwise the Scrum Team creates it, the Developers are required to conform to it, and the team inspects it in each Sprint Retrospective. Testers contribute by proposing checkable quality criteria, backed by the defects that escaped.

Does a DoD replace the exit criteria in a test plan?

For the work inside a sprint it usually takes their place. Projects with contractual or regulatory obligations, or with separate test levels such as acceptance testing by a customer, often still define exit criteria for those levels or for a release in a test plan.

References

Tools

Practise with Mutqan tools

Requirements → Test Cases

Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.

Test Design

Go deeper

Your progress on this topic

Part of the QA Roadmap

Next topics