A work item moves to Done in Jira, the sprint board looks healthier, and everyone can see another story completed. Then QA finds an untested edge case, security asks for evidence, or the Product Owner discovers that the feature cannot be used without a configuration change. This is precisely why teams need to know how to define done criteria: not as a ceremony artefact, but as an operational control for delivery quality.
Done criteria establish the minimum conditions that must be true before work can be represented as complete. They protect forecast accuracy, reduce the volume of hidden work, and give delivery leaders a defensible view of what is genuinely ready to release.
What done criteria are - and what they are not
Done criteria are the observable, verifiable conditions that apply when a product increment, backlog item, or other unit of work reaches completion. In Scrum, this is commonly expressed through a Definition of Done. In Kanban or hybrid delivery environments, the same logic may sit behind a workflow policy for the Done column or a release-ready state.
The key word is verifiable. “Code is good quality” is a useful aspiration, but it is not a completion criterion. “Code has passed automated checks, peer review and agreed static analysis thresholds” can be checked, evidenced and consistently applied.
Done criteria are also different from acceptance criteria. Acceptance criteria define what a specific backlog item must do from the user or business perspective. Done criteria define the engineering, operational and governance standard that every applicable item must meet. A story might meet its acceptance criteria while still failing the team’s done standard because test automation, documentation, accessibility checks, or deployment evidence is incomplete.
That distinction prevents a common failure mode: treating functional demonstration in a sprint review as proof that work is ready for production.
Start with the delivery risk, not a generic checklist
The fastest way to create a weak Definition of Done is to copy a checklist from another organisation. The fastest way to create an unusable one is to include every possible control, regardless of risk or work type.
Start by examining where completed work regularly returns. Look at production defects, support escalation themes, late security findings, release delays, failed handovers and unplanned configuration work. These are not isolated quality problems. They are evidence that the current completion boundary is too vague or too narrow.
For example, a team building an internal reporting tool may not need the same performance test evidence as a customer-facing payments service. Conversely, the payments team cannot treat a basic code review as sufficient when auditability, resilience and security are material delivery risks. The standard should be proportionate, but never optional by convenience.
Ask three practical questions for each recurring issue:
- What condition should have been true before this item was marked Done?
- Who can verify that condition without relying on personal judgement?
- What evidence should remain available after the sprint or release?
How to define done criteria that teams can use
A workable done standard should be created jointly by the people accountable for delivery: engineers, testers, Product Owners, designers where relevant, platform or operations specialists, and security representatives for regulated or high-risk products. The Scrum Master or Agile Coach should facilitate the decision, but should not impose a standard without team ownership.
Begin with the smallest unit you want to govern, usually a backlog item. Define what must be true before it can pass into Done. Then identify whether additional criteria are needed at increment, release or deployment level. This layering matters. A story can be complete from a development perspective while a release still requires approval, migration validation or operational readiness checks.
Write each criterion in plain, testable language. Good wording identifies the action, standard and evidence. For example:
- “Peer review completed” is better than “reviewed”.
- “Automated regression tests pass in the delivery pipeline” is better than “tested”.
- “Known exceptions are documented and accepted by the named accountable owner” is better than “risks considered”.
Build a baseline across four control areas
Most software teams need a baseline that covers functional fitness, engineering quality, operational readiness and traceability. The exact controls vary, but these four areas prevent the most common gaps.
Functional fitness confirms that agreed acceptance criteria are met and that the Product Owner can validate the intended outcome. Engineering quality covers code review, automated testing, agreed technical standards and defect handling. Operational readiness addresses deployment, monitoring, support guidance, feature flags, configuration and rollback where applicable. Traceability ensures the work item contains the right links, evidence, decisions and approvals for the team’s context.
A practical baseline might state that each completed story has met acceptance criteria; has been peer reviewed; has passed required automated tests; has no unresolved critical or high-severity defects; has updated technical or user documentation where the change requires it; and has been deployed to the agreed environment.
Do not make all criteria universal if they plainly are not. A documentation update may be irrelevant for a low-level refactor, while a database migration may need specific rollback evidence. Use a core standard plus explicit, pre-agreed conditional criteria. That is more disciplined than letting people make exceptions informally at the end of a sprint.
Make ownership and evidence explicit
A done standard without ownership becomes a hopeful poster. Every criterion needs a clear way to verify it and a role responsible for confirming it. This does not mean creating a bureaucratic approval chain. It means removing ambiguity.
For a code review, the pull request record may be the evidence and an engineer other than the author may verify it. For accessibility, evidence might be an automated scan plus a targeted manual check, owned by the delivery team with specialist support where necessary. For a release note, the Product Owner may confirm that customer-facing changes are accurately described.
Where possible, build evidence into existing tools and workflow automation. Pipeline results, test reports, pull request status, ticket fields and release records should support the standard. Manual evidence is still appropriate for judgement-based work, but teams should not spend hours copying data between systems merely to prove that routine controls happened.
This is where many Jira configurations go wrong. Teams add a Done status, but allow tickets to transition there without verifying anything. A better design uses required fields, linked evidence, workflow validators or automation for the controls that can be checked consistently. Keep the workflow practical: if a validator creates workarounds, it is enforcing the wrong thing or enforcing it at the wrong point.
Test the criteria against real work
Before formalising the standard, take a recently completed story, a production defect and a technically complex change through it. If the team cannot determine whether each item is Done without debate, the wording needs tightening.
Also test the cost. A standard that requires excessive manual administration will be bypassed under delivery pressure. The answer is not to remove quality controls. It is to simplify evidence, automate repeatable checks and move work earlier in the flow. Security review, test design and operational planning should not appear only when a story is supposedly finished.
A useful challenge is this: could a new team member apply the criteria correctly after a short explanation? If not, the standard probably depends too much on tribal knowledge.
Review the standard as delivery conditions change
Done criteria should be stable enough to create discipline, but not frozen indefinitely. Review them after material incidents, major changes to architecture, new regulatory obligations, platform migrations or repeated failure patterns. A quarterly review is often sensible for established teams, while a new team may need to inspect the standard more frequently during its first few sprints.
Measure whether the standard is working through outcomes rather than checklist completion alone. Watch escaped defects, reopen rates, lead time after code complete, release failure rate, unplanned work and the percentage of items that cannot be released after being marked Done. If these measures do not improve, investigate whether criteria are weak, inconsistently applied, or disconnected from the actual risks.
Agile Toolkit Lab treats a Definition of Done as a delivery asset: a concise, visible agreement that makes quality repeatable under pressure. Its value is not the document itself. Its value is the moment a team can say “Done” and mean it without qualification.
The best closing test is simple. Before moving work to Done, ask whether a colleague outside the immediate delivery conversation could deploy, support, audit or build on it safely. If the honest answer is no, the work is not late. It is simply not done yet.