Definition of Done: what counts as finished work, with an example

“I'm finished” is not yet a shared standard

Definition of Done describes the quality conditions for a completed result.

The developer finishes the form, the editor prepares the copy, and the person checking it discovers that the confirmation never arrives. Everyone has done their part, but a visitor still cannot book reliably. This is where a shared completion agreement helps: it connects individual actions to a usable result.

In Scrum, Definition of Done concerns the state of the Increment and its quality requirements. Below, we apply the idea to an illustrative workshop booking form. The specific conditions are an editorial example for discussion, not a universal standard to copy unchanged into every team.

DoD, acceptance criteria and DoR answer different questions

A story's criteria usually change with its purpose. Cancelling a booking needs different conditions from choosing a session. The shared quality standard remains: changes must work with the rest of the product and pass the agreed checks.

Definition of Ready is an optional team agreement, not a mandatory element of the Scrum Guide. You do not need matching documents simply because two convenient abbreviations exist. Start with the gap that actually causes rework.

A Definition of Done example for a small web product

In our example workshop, the team has already agreed on the form's scenarios. It now wants to stop handing over “nearly finished” changes. A working draft of the DoD could look like this:

1. The change is integrated into the current product version and checked alongside the affected scenarios.
2. The agreed story criteria are met, and the check results are available to the team.
3. The main path and anticipated errors are checked on the agreed devices.
4. No known defects remain that, under the agreed policy, block use of this version.
5. User-facing copy and affected instructions match the behaviour.
6. Changes and limitations needed for ongoing support are recorded.

For each condition, specify where the evidence can be seen. “Everything is tested” cannot be checked unambiguously. “The available and fully booked session scenarios passed on mobile and desktop, with results attached” makes it possible to discuss whether the checks are sufficient. Choose devices for your own product, not because they appear in this example.

Working through a disputed completion

Suppose the form accepts contact details and shows a confirmation, but a second click creates two bookings. The developer considers it finished because the main scenario passes. The reviewer objects because one visitor can take two places. The decision depends on the agreed conditions and the defect's impact, not on who argues most persuasively.

The team reproduces the issue, connects it to the criterion that prevents duplicate bookings and saves the example. Until that criterion and the shared quality policy are met, the work does not meet the completion agreement. Moving the defect into a new task does not, by itself, make the original result complete.

Consider another situation: the form fully meets the DoD, but the workshop opens enrolment on Monday. Readiness and the chosen publication date are different things. Waiting for a marketing announcement does not necessarily mean the technical result is unfinished; release timing is a separate decision.

Agreeing on a standard without a huge checklist

Collect two or three recent cases where work was sent back. Record what was missing: a joint check, clear copy, error handling or instructions. Those recurring causes make a more useful draft than a long list borrowed from elsewhere.

Then try each condition against a specific change. Who can see that it is met? Is the required environment available? What happens if the check fails? Without answers, you have an aspiration rather than a working agreement.

Do not turn the DoD into a description of every process step. “We had a call on Wednesday” is an action that may not affect the result's quality. “The reviewer reproduced the scenario and saw the expected outcome” is a meaningful condition. Keep the latter in the document and discuss organisational habits separately.

Responsibility and when to review the standard

Completion should not depend on one reviewer's personal judgement alone. Participants need a shared understanding of the standard and must know where to find the evidence. If multiple Scrum Teams work on one product, they need a shared Definition of Done so the Increment has consistent quality.

Review the standard after a recurring defect, a product change or the discovery of an unnecessary check. Record the new version and when it applies. Do not quietly weaken criteria retroactively just to turn the current report green.

If you want to add twenty conditions at once, consider each one's cost. A check should protect against a specific risk. Sometimes automation makes the standard cheaper to meet; sometimes removing an ambiguous word is enough. Document length alone does not improve quality.

Where to keep the working result

In Sinqly, you can create a task called “Check the booking form is ready” and add the shared quality agreement and links to specific check results to its description. Signing up is free.

DesktopMobile

View screenshot ↗

Close ×

A real Sinqly task card from the screenshot library, showing the description field in a different illustrative example. The screenshot uses Russian demo data. You enter the article's content manually; it does not show a dedicated specialist module.

What to check before saying “done”

Take the last completed task and ask: could another participant understand why it is finished without messaging the person who did it? If not, add the missing evidence rather than another status: a checked scenario, a test result or a link to the agreed document.

Then compare the next two results against the same standard. The aim is not to prevent every small task from being finished, but to stop the word “done” from meaning something different to each person.

Acceptance criteria for a specific task help complement the shared standard with the expected behaviour.