Definition of Ready, Done and release criteria

Three gates, each answering a different question, each owned by someone different. Most teams have vague versions of all three in their heads, and the disagreements that follow are usually not disagreements about the work — they are disagreements about which gate applies.

Definition of Ready

Owned by whoever brings the work. The purpose is to protect the team from receiving work they have to decode.

[ ] The problem is stated, not just the requested solution
[ ] Acceptance criteria are written and testable
[ ] Design or interface is available, where one is needed
[ ] Dependencies identified and resolved, or explicitly accepted as a risk
[ ] Sized by the people who will do the work
[ ] Non-functional expectations stated where they matter
    (performance, volume, access rules)
[ ] Someone is available to answer questions while it is in progress

The last item is the one that gets skipped, and it is the difference between a two-day task and a two-week one. Ready does not only mean the description is complete; it means the context is still reachable.

Definition of Done

Owned by the team. The purpose is that “done” means the same thing to everyone, including people outside the team.

[ ] Acceptance criteria met and verified against them, not against intent
[ ] Reviewed by someone who did not write it
[ ] Automated checks pass — build, static analysis, security scanning
[ ] Tested in an environment that resembles production
[ ] Accepted by whoever asked for it
[ ] Documentation updated where behaviour changed
[ ] Monitoring or logging added if this introduced something worth watching
[ ] Deployed, or in a state where deployment requires no further work

“Deployed, or requiring no further work” is deliberately worded that way. If done means merged, you accumulate an invisible queue of finished-but-not-shipped work, and every estimate downstream becomes fiction.

Release criteria

Owned by whoever is accountable for production. The purpose is that a release is a decision with conditions, not an event on a calendar.

[ ] Every item in the release meets Definition of Done
[ ] Automated checks green on the release candidate, not on an earlier build
[ ] Non-functional checks run against a production-like environment
[ ] Migrations reviewed, and reversible or with a tested forward fix
[ ] Rollback path known and stated, with a time estimate
[ ] Verification steps written before the release, not improvised after
[ ] Stakeholders informed, where the change is user-visible
[ ] Someone who can roll back is available for the window afterwards

Why these fail, and the fix

They fail by growing. Each incident adds an item, nobody ever removes one, and within a year the checklist is long enough that it gets ticked as a block rather than read.

Two counters. Every item must be checkable in under a minute, or automated — if verifying an item is itself a project, it belongs in the pipeline, not on the list. And review the lists on a fixed cadence with the specific intent of deleting items, not adding them. If an item has never failed, it is either automated already or it was never a real risk.

The part that makes all three survivable

None of it works if the iteration is planned as if every available hour goes to new work.

Planned work                   ~70%
Support, defects and buffer    ~20%
Technical improvement          ~10%

Exact numbers should match your context; what matters is that the split is written, visible during planning, and used rather than quoted afterwards.

The reasoning is not generosity. Support work arrives whether or not you planned for it — the only question is whether it appears in the plan or silently consumes the work that was in it. And technical improvement is the only category with no external deadline, which means it loses every prioritisation conversation forever unless it has a reserved share.

Alongside the split you need a written rule for what may interrupt a committed iteration. In practice that should be one severity level and no more; if two levels can interrupt, everything becomes the higher of the two within a month.