A backlog item can sound perfectly sensible in refinement and still fail on day two of a sprint. The usual cause is not poor engineering effort. It is that the team treated the definition of ready vs acceptance criteria as interchangeable, then discovered gaps in scope, decisions, access, or testable behaviour once delivery had already started.
For delivery leaders, the distinction is operational rather than academic. A Definition of Ready protects the team’s ability to start work with confidence. Acceptance criteria define what the completed solution must do for a specific backlog item. Used together, they reduce mid-sprint negotiation, make quality expectations visible, and give Product Owners, engineers, and testers a common basis for decisions.
Definition of Ready vs Acceptance Criteria: the core difference
The Definition of Ready, often shortened to DoR, is a shared policy for deciding whether a Product Backlog Item is sufficiently understood and prepared to enter a sprint or flow into active delivery. It answers one question: are we ready to start?
Acceptance criteria are the conditions a particular backlog item must satisfy to be accepted by the Product Owner or relevant business representative. They answer a different question: what must be true for this work to meet the intended need?
The difference is easiest to see through timing. A team applies its Definition of Ready before committing to or pulling work. It uses acceptance criteria while building, testing, reviewing, and accepting that specific item. DoR is a reusable readiness standard; acceptance criteria are item-level expectations.
That does not mean readiness is a bureaucratic gate. A team that turns its DoR into a long approval process will slow learning and create a refinement backlog of its own. The aim is to expose genuine blockers before work begins, not to demand certainty where discovery is required.
What a Definition of Ready should control
A useful Definition of Ready makes invisible preparation work explicit. It should set a minimum standard that allows a cross-functional team to begin delivery without spending the first half of the sprint chasing basic answers.
For a typical software team, a ready item will normally have:
- a clear problem, user outcome, or business objective;
- an identified Product Owner or decision-maker available to answer questions;
- enough scope detail for the team to estimate or size the work appropriately;
- known dependencies, constraints, and required access called out;
- an agreed approach to validation, including relevant acceptance criteria; and
- a size that fits the team’s planning horizon or flow policy.
The point is consistency. If a team repeatedly starts items without environments, designs, decisions, or dependency commitments, it has a readiness problem. Calling that work “Agile” does not remove the cost. It simply hides the cost in blocked work, carry-over, unplanned meetings, and unreliable forecasts.
Keep DoR at the right level
A Definition of Ready should not dictate implementation design for every item. “Database table designed”, for example, is too prescriptive unless the work genuinely depends on that decision being made first. Likewise, “all edge cases documented” is often unrealistic for exploratory work.
A better rule is that the team understands enough to make a responsible start, identify the main risks, and agree how it will know whether the intended outcome has been achieved. If an item contains a significant unknown, make that visible. Create a discovery task, spike, or research item with its own clear objective rather than disguising uncertainty as delivery certainty.
What acceptance criteria should define
Acceptance criteria describe the observable behaviour, rules, constraints, or outcomes expected from one backlog item. They turn an intent such as “allow customers to change their delivery address” into conditions that can be built, tested, and accepted.
Strong acceptance criteria are specific enough to remove ambiguity without becoming a full technical specification. They should focus on what the user or business needs, including meaningful failure paths and rules. They do not need to prescribe every internal component, API call, or database change unless that detail is itself an acceptance condition.
Consider this backlog item: “As an account holder, I want to update my mobile number so that I can receive security notifications.” Its acceptance criteria might state that a user can update a valid UK mobile number from account settings; the system sends a verification code to the new number; the old number remains active until verification succeeds; and an invalid or expired code produces a clear message without changing the stored number.
Those conditions make the expected behaviour testable. They also surface questions early: What counts as valid? How long is the code active? Is there a rate limit? Does the update require re-authentication? The criteria do not have to answer every technical question, but they should expose the business decisions that matter to acceptance.
Examples are useful, but not enough
Teams often write acceptance criteria in Given-When-Then format. This can be highly effective where it helps create a shared understanding and supports automated acceptance testing. For example: Given a verified account holder, when they submit a valid new mobile number and correct verification code, then the account profile is updated and a confirmation is displayed.
However, formatting is not quality. A poorly thought-through requirement can still be written in flawless Given-When-Then syntax. Use the format when it clarifies behaviour. Do not force every item into scripted scenarios if concise rules, examples, or a decision table communicate the need more clearly.
Do not confuse either with the Definition of Done
The most common source of quality drift is mixing up readiness, acceptance, and completion. The Definition of Done is the team’s standard for work that is actually complete. It commonly covers activities such as peer review, automated tests, security checks, documentation, integration, and deployment evidence where appropriate.
Acceptance criteria establish whether the specific feature meets its intended functional or business need. The Definition of Done establishes whether the work meets the team’s overall quality standard. A story can meet every acceptance criterion and still not be done if it has not passed required testing or integration. Conversely, an item can comply with the Definition of Done process while failing a key acceptance criterion.
Scrum does not prescribe a mandatory Definition of Ready. Teams should not present it as an official Scrum artefact or use it to deny collaboration. The Definition of Done, by contrast, has a defined role in Scrum. That distinction matters when coaching teams: DoR is a deliberately chosen working agreement, not a substitute for product ownership or a licence to postpone difficult conversations.
Build a practical operating model
The most effective setup is lightweight, visible, and reviewed through delivery evidence. Start with a short team-level DoR that covers the recurring causes of churn. Then ensure each backlog item has acceptance criteria proportionate to its risk and complexity.
During refinement, the Product Owner explains the desired outcome and business rules. Engineers identify technical constraints, dependencies, and uncertainty. Testers challenge ambiguity by asking how the outcome will be verified. The group should leave with one of three outcomes: the item is ready, it needs a defined piece of follow-up work, or it is intentionally deferred.
At sprint planning or replenishment, apply the DoR consistently. If an item fails the readiness check, do not quietly pull it in because the team wants to appear fully utilised. Choose another ready item, reduce the commitment, or explicitly reserve capacity for discovery. Starting unready work to fill capacity often produces less value than starting less work with greater clarity.
During delivery, acceptance criteria should remain visible in the work item, test approach, and review conversation. They are not a document to write once and ignore. If a criterion changes because the business has learned something, update it transparently and assess the effect on scope, forecast, and release expectations.
Measure whether the standards are helping
A DoR and acceptance-criteria practice is working when it improves flow, not when it creates more fields in Jira. Watch for blocked days caused by unanswered questions, the percentage of work carried across a sprint, defects escaping acceptance, rework after sprint reviews, and the time between starting an item and receiving meaningful feedback.
If refinement becomes lengthy but carry-over remains high, the team may be documenting detail without resolving dependencies. If engineers frequently challenge acceptance criteria late in the sprint, Product Owners may need better examples, earlier tester involvement, or faster access to domain experts. If ready items wait too long in the backlog, the DoR may be too strict for the team’s actual capacity and uncertainty profile.
Treat the standards as operational tools. Review a small sample of recently completed and recently delayed items every few weeks. Ask what readiness signal was missing, which acceptance criterion was unclear, and whether the rule would have changed the outcome. This keeps the practice connected to delivery reality rather than process theatre.
A disciplined team does not seek perfect requirements before it starts. It creates enough shared clarity to move decisively, then uses acceptance criteria and feedback to keep the work anchored to the outcome that matters.