Task acceptance criteria: how to write and check them, with examples

Acceptance starts before the work

Acceptance criteria are the conditions used to check the expected result of a specific task.

“Make booking convenient” leaves too much room for different interpretations. The person doing the work may build a form, the client may expect an email confirmation, and the reviewer may expect protection against booking a full session. Everyone is discussing one task but expecting different results.

Good criteria turn expectations into observable behaviour. Below, we work through an illustrative workshop booking form. These are requirements for a fictional website, not a list of Sinqly features. The method also applies to a document, a design or organisational work.

Start with the result and boundaries

First, name what the person should get. In our example, a visitor chooses a session, provides contact details and understands whether the booking succeeded. Payments, a loyalty programme and moving a booking to another date are outside this task. These exclusions help keep acceptance from becoming an endless expansion of the work.

Then clarify the starting conditions: which fields are required, where availability comes from and what counts as a repeat submission. Without that, even a detailed checklist will rest on different assumptions.

Do not start with dozens of failure scenarios before agreeing on the main path. Work through a normal successful booking first, then input errors and constraints. This keeps the goal in view and avoids getting lost in details outside the chosen scope.

Five criteria for a booking form

In a real project, refine the last row for the known errors. “Every error is understandable” is too broad again. Name the specific failure, acceptable message and ability to retry safely.

The single-booking criterion also needs a boundary: clicking again, repeating a request and deliberately making another booking may be different scenarios. If the wording can be read two ways, add sample input and the expected outcome.

How a criterion differs from a technical solution

“Use library X” describes an implementation choice. “Do not create a second booking when the confirmation is repeated” describes behaviour. Both requirements may matter, but keep them distinct: the first is checked as a solution constraint, the second as an outcome for the user and system.

For a design, a criterion might require the agreed form states and readable labels at a chosen width. For a document, it might require answers to specific questions and no unsupported claims. Not every kind of work needs to become a software test.

Do not copy every shared quality requirement into each task. Link to the current standard and keep the result-specific conditions here. This reduces differences between copies and makes the task easier to read.

Working through an acceptance dispute

The person doing the work shows the form: it will not submit with empty contact details, but the visitor sees no explanation. The criterion only said “required field”. The client expected a helpful message; the developer considered blocking submission sufficient. This is not a reason to argue about who should have guessed. The original agreement was ambiguous.

Clarify the criterion: after a submission attempt, an error appears beside the field, identifies the missing contact information and disappears after correction in the intended scenario. Then assess the scope change and agree on the action. If the requirement is new, honestly call it a clarification rather than a proven mistake by the person doing the work.

Consider a different situation: the message was explicitly agreed but not implemented. In that case, the check shows that a criterion is unmet. Keep the version of the conditions and an example of the result, so acceptance relies on facts rather than participants' memories.

How to organise the checks

1. Agree on the criteria with the people doing and accepting the work.
2. Prepare data for the normal scenario and the main errors.
3. Work through every criterion and save the observable result.
4. Separate unmet commitments from new improvement ideas.
5. Record the outcome: accepted, needs a fix or needs another decision.

A screenshot is useful for a visible state, but does not always prove behaviour. One image of a confirmation does not establish that resubmitting is safe. Match the evidence to the condition: a sequence of actions, a record of the check or a test result.

Do not lengthen the list just to make it feel reliable. You can combine repeated items, but do not hide different consequences behind “everything works”. A good check is specific enough for another participant to repeat it and understand a discrepancy.

Where to keep the working result

In Sinqly, you can create a task called “Agree on acceptance for the booking form” and add the conditions, sample data and check results to its description. Here, Sinqly is a place to record agreements. 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.

How to improve one current task

Look for words such as “high-quality”, “convenient”, “fast” or “correct” in the description. For each one, ask what the reviewer will actually see. Sometimes one example is enough; sometimes a measurable threshold and its measurement conditions are needed. Do not add a number unless it is clear how and where it will be measured.

After clarifying, ask the person doing the work to describe one boundary case. If your expectations match, the task is better prepared. If not, a short conversation now is usually more useful than a long argument at handover.

A shared Definition of Done complements task criteria with a consistent quality standard.