Definition of Ready and Definition of Done: The Two Quality Gates BAs Actually Control

A story enters sprint planning. The developer asks three questions the BA thought were answered. They weren’t written down. Development starts anyway, on a shared assumption that turns out to be wrong. Two days later, someone finds the gap.

Or: a story is marked done. A business user picks it up in UAT and raises issues that feel obvious in hindsight. The developer says it met the acceptance criteria. The BA looks at the criteria and sees the problem: they were met technically, but not in the way anyone actually meant.

Both are quality failures. Both were paid for at the wrong point. And both are predictable when a team has no shared agreement on what “ready” means before a story enters a sprint, or what “done” means when it leaves development.

Definition of Ready and Definition of Done are the agreements that prevent this. They are not Agile ceremony. They are two lightweight checkpoints that bracket the BA’s work on a story: one at the entry point, one at the exit. The BA’s job is to shape them, use them, and keep them honest.

5-Minute Learning summary

Technique:
Definition of Ready and Definition of Done

Helps with:
Stories entering sprints with unresolved gaps, and “done” meaning different things to different people

BA move:
Shape and maintain both agreements: DoR as the entry gate before a story enters development, DoD as the exit gate that must include acceptance criteria validation

What goes wrong without them

When a team has no Definition of Ready, the sprint becomes the discovery phase. Gaps that should have been resolved in refinement surface during development. The developer stalls, asks questions, waits for answers, or makes a call and builds on an assumption. Sometimes the assumption holds. Often it doesn’t.

When a team has no Definition of Done, “done” means whatever the person marking it thinks it means. For the developer, it might mean the code is written and reviewed. For QA, it might mean the main scenarios passed. For the business user, it means something different again. The story closes. The gap surfaces in UAT.

Neither failure is dramatic. They accumulate quietly, sprint by sprint, until the project is carrying a weight of small misfires that nobody ever formally named.

The two techniques in plain language

Definition of Ready and Definition of Done solve different problems at different points in the story lifecycle. They are not two versions of the same idea.

Definition of Ready is a set of criteria a story must meet before it enters a sprint. Not a guarantee of perfection. A minimum bar for clarity. The team agrees upfront what “ready” looks like, and stories that don’t meet it don’t get pulled into planning.

Typical DoR criteria: the story has a clear user goal, acceptance criteria are written and agreed, dependencies are identified, and any decisions that would block development are resolved. The exact criteria should reflect what keeps causing problems on your project. If half your mid-sprint questions are about edge cases, edge cases go on the list.

The BA’s role in DoR is to make sure the criteria exist, know what they are, and not let a story through that isn’t ready. That last part is the one most often skipped. Having a DoR and then pulling stories through anyway because the sprint needs filling is the same as not having one.

Definition of Done sits at the other end. Once development is finished, DoD is the checklist that confirms the story is actually ready to move forward to QA, to UAT, to release, depending on your pipeline. It is not a mirror of DoR. It is a different agreement about a different question: not “can we start?” but “is this actually finished?”

A DoD typically covers: development complete, code reviewed, tested to the agreed level, no known blockers. But from the BA’s perspective, one condition matters above all others: acceptance criteria validated. Not just “the developer thinks it meets the criteria.” Validated. Checked against the intent of what was written, not just the literal wording.

If the BA’s criteria haven’t been reviewed, the story isn’t done for BA purposes. This condition should be explicit in the DoD, not assumed. A DoD that ends at technical completion leaves the BA’s work unfinished. If acceptance criteria validation isn’t on the list, propose adding it.

A project situation

A mid-sized software project. Four-week sprints. A BA and a small dev team. No formal DoR or DoD. Stories are refined in backlog sessions but nobody has agreed on what “ready” or “done” actually means.

What happens without DoR:

A story for a request approval workflow enters sprint planning. The developer asks: what happens if the approver is on leave? The BA says they’ll check. Development starts anyway. Two days in, the answer changes the routing logic. The work done so far doesn’t fit. Part of the story is rebuilt.

With a DoR in place, that question is on the must-be-resolved list before the story is ready. It gets answered in refinement, not mid-sprint. One conversation at the right time. No rebuild.

What happens without DoD:

Three weeks later, the same story is marked done. QA confirm the main scenarios passed. The BA picks it up and notices the notification sent to approvers contains no information about what actually needs to be approved. Just a system alert with a link. Technically, it matches the acceptance criteria wording. Practically, it is not what anyone meant.

The developer marked it done because the code works. QA marked it done because the test passed. Nobody checked whether the outcome matched the intent of the criteria.

With a DoD that includes “acceptance criteria validated by BA”, the BA reviews the story before it closes. The gap is caught before UAT. A short conversation, a fix, done properly.

Two different failures. Two different gates. One at the start of the sprint, one at the end.

How a BA applies Definition of Ready and Definition of Done

Step 1: Find out whether DoR and DoD exist on your project. If they do, read them. Check whether BA sign-off on acceptance criteria appears as an explicit condition in the DoD. If neither exists, that is your starting point.

Step 2: Draft a DoR if one is missing. Start with four to six criteria. Suggested minimum: the story has a clear user goal, acceptance criteria are written and agreed, dependencies are identified, blocking decisions are resolved, and the story is understood well enough to estimate. Run it past the team and refine it.

Step 3: Check the DoD includes acceptance criteria validation as an explicit exit condition. “Dev complete and tested” is not sufficient. The criteria should be reviewed against the intent of what was written, not just the literal wording. If this condition is missing, propose adding it.

Step 4: Use the DoR actively at refinement. Before a story is added to the sprint candidate list, ask whether it meets the criteria. Be willing to say it is not ready. That conversation is cheaper than a mid-sprint stall.

Step 5: Use the DoD as a BA review prompt when a story is marked done. Work through it yourself. Does the build meet the intent of the acceptance criteria? Are there conditions that haven’t been validated? Do not assume someone else has done this check.

Step 6: Revisit both after retrospectives. Ask what caused a story to stall or be reopened. Did the DoR or DoD miss something? Update them. They should get sharper over time, not stay static.

If your project’s UAT keeps surfacing issues that should have been visible at the story level, the IT Project Problem Diagnostic Checklist includes a UAT Readiness section. Use it to check whether your acceptance criteria, test scenarios, and story quality gates are in place before UAT begins.

Common mistakes

Treating DoR as someone else’s job. If stories are arriving at planning without clear acceptance criteria, the BA is part of the problem. DoR is not a Scrum Master artefact. The BA should own the requirements-side criteria within it.

Making DoD a compliance checklist. Five to eight criteria is usually enough. A DoD with fifteen items becomes something the team scrolls past. A short, sharp list that gets used is worth more than a thorough one that doesn’t.

Using DoR after the sprint starts. Using it to explain why a story is struggling mid-sprint is using it as a blame tool. Its value is at the entry point. If the story is already in the sprint, the gate has already opened.

Letting DoD drift to “tech done”. This is the most common BA-specific failure. If acceptance criteria validation is not explicit in the DoD, it gets assumed, skipped, or left to whoever closes the ticket. Make it explicit.

Treating both as fixed agreements. DoR and DoD should evolve as the team learns what keeps causing problems. Review them after retrospectives. Update them when the same failure mode keeps appearing.

Confusing DoR with story completeness. A story does not need to be fully detailed to be ready. It needs to meet the agreed minimum bar. Set the bar too high and nothing gets through. Set it at the point where development can start without stalling.

When to use it and when a lighter approach is fine

DoR and DoD earn their place when stories regularly enter planning with unresolved gaps, when “done” means something different to each team member, when stories keep being reopened or failing UAT for reasons that should have been caught earlier, or when the team is large or distributed enough that informal norms don’t hold consistently.

A lighter approach is genuinely fine when the BA and developer work closely enough that gaps surface in conversation naturally. On a very small, co-located team, a formal DoR can add friction without adding much benefit. The informal equivalent already exists.

It is also fine to hold off early in a project. If the team hasn’t yet generated enough stories to know what their common failure modes are, observe first. Introduce DoR and DoD once patterns emerge rather than front-loading process before you know what you’re solving for.

And if the work is a spike or discovery piece where “done” is intentionally exploratory, apply a modified version or skip the standard DoD entirely. The standard definitions are built for delivery stories. Not everything is a delivery story.

A Definition of Done that ends at technical completion leaves the BA’s work unfinished.

FAQ

Is Definition of Ready the same as a story being groomed?
Grooming or refinement is the activity. Definition of Ready is the standard the story has to meet as a result. A groomed story isn’t automatically ready — it depends on whether it meets the agreed criteria.

Who owns the Definition of Done?
The DoD is a shared team agreement. But the BA should own the acceptance criteria validation condition within it. If that condition is missing from the DoD, or isn’t being used, the BA is the right person to raise it.

Do DoR and DoD need to be the same for every story?
The standard versions apply to most stories. Spikes, technical debt items, and discovery work may need modified versions. Agree the base definitions for the majority of your backlog and handle exceptions case by case.

What if the team won’t agree on either?
Start with the problem, not the solution. Point to specific examples where stories stalled mid-sprint or failed UAT for reasons that should have been caught earlier. Most teams will agree to a shared gate once the cost of not having one is visible.

Is DoR only for Scrum teams?
The label is Scrum-adjacent, but the idea applies to any team working from a backlog. If your team doesn’t use the term, use the concept. Call it something else if that helps it land.

What to do next

Take one story currently being refined or close to the sprint candidate list. Ask: would it pass a Definition of Ready right now? If your team has no DoR, that question alone will show you the gap.

Then look at the last story marked done. Ask: was the acceptance criteria checked against the intent of what was written, or just the literal wording? If that check didn’t happen, your DoD is missing something.

Both questions take five minutes. The answers usually take longer to sit with.

If requirement gaps and UAT surprises keep appearing on your project, the IT Project Problem Diagnostic Checklist can help you see where in the delivery pipeline the breakdown is happening. Before it compounds.