Two questions, two checkpoints
Definition of Ready (DoR) asks: do we understand enough to start this work responsibly? It is a team agreement about the information needed before taking a ticket into development. Acceptance criteria (AC) ask: what observable result will show that the work is done?
DoR is applied before development. AC are usually written before development too, but checked against the completed change. Definition of Done (DoD) is a team-wide standard for completed work, such as review, agreed tests and release steps. These are examples, not a universal DoD. A team can have AC on a ticket that is still not ready: the goal may be clear while permissions or an API contract remain undecided.
DoR is not a universal certification. A small copy change needs less detail than a new payment flow. The agreement should help the team expose costly uncertainty, not demand a long form for every task.
One ticket: export filtered invoices
Draft: “Add an invoice export for finance.”
Before the team starts, its DoR check could require answers to these questions:
- Is “finance” an existing role or a new permission? Who owns that decision?
- Does export include the visible page or all records matching filters?
- Which columns, file format and date range are required?
- Is the reporting API available, and is there a design for the export action?
- Who will verify the result and with which test data?
Once those answers are confirmed, the AC could be:
- A user with the confirmed Finance Export permission can download a CSV for the selected date range.
- The file contains every invoice matching the active filters, including records on later pages.
- A user without that permission cannot start the export.
- An empty result produces the agreed empty-file behaviour.
The permission name and empty-file rule above are examples, not decisions a generator should invent. The ticket owner must confirm them. Read the acceptance criteria guide.
When is a ticket ready?
It is ready when the remaining uncertainty is small enough for the team to start without committing to an unknown outcome. Open questions can remain if they are recorded, owned and do not block the first meaningful step. A blocker is a decision whose answer changes the scope, architecture or testable outcome.
Use the task readiness tool to surface missing decisions before refinement. Then let the team make the start decision. The task readiness checklist provides a short review.