Task acceptance criteria describe an outcome you can verify before treating work as done. Record conditions for the particular recipient, scope and relevant edge cases. Identify the reviewer too: performing an action and accepting its result are not automatically the same stage.
Turn “update the price list” into an observable outcome
“Update the website price list” gives direction but leaves questions. Which services, which source file, which page, and must the change be published?
One person updates draft content while another expects the live page. Criteria should resolve that difference before work begins. The outcome must identify what the recipient can actually inspect.
Avoid describing only editor clicks. “New amounts entered” confirms an action, not that the recipient sees the correct prices. A better condition is “the specified public page shows entries from the approved source”. The guide from support request to task explains connecting the original need to the resulting work.
The outcome should match the commission. If the client wants prices corrected, do not silently add a calculator or rebuild the entire page. Criteria are not a collection of every team idea.
A defined acceptance scope later distinguishes unfinished agreed work from a new request, without dismissing the usefulness of the new idea.
Build each criterion from context, condition and observation
Complete the sentence: “In this place, with these inputs, this result should be visible.” For the price list, the context is a particular page, the inputs are approved amounts and the observation is the accessible table. Avoid “nicely”, “correctly” or “quickly” without explanation. Two people should be able to assess the same condition similarly.
- Choose the outcome.Identify what the recipient will see or do. Do not replace the result with a performer’s action list.
- Identify the scope source.Name the approved input version and change location. “According to the file” is ambiguous when several copies exist.
- Add a verification method.Define an observation for judging the condition. For a visible table, inspect the particular page with the relevant data.
- Separate another idea.Record what falls outside this task when it was discussed. Acceptance should not expand without a decision.
A criterion need not be a technical test script. A clear condition verifiable by the reviewer is enough. The implementation approach can remain with the performer. For a user-reported bug, the customer bug task template covers complete input context; acceptance conditions answer a narrower question about the expected outcome.
An acceptance card for a price-list update
Original example: the client approved “price list version B” for three services on one page. The team must change the public table and its link to the same document version. A redesign is not agreed. These conditions identify what counts as the outcome of this particular task rather than assuming publication and document changes are obvious.
Scroll the table sideways to see all columns.
| Condition | How to assess the result |
|---|---|
| Three-service scope | The table contains specified names and amounts from version B. |
| Public outcome | The relevant page shows updated data after publication. |
| Document link | It opens approved file B rather than the earlier copy. |
| Phone readability | Names and amounts remain visible without important characters being cut off. |
| No unagreed change | Other sections and service scope were not expanded. |
| Acceptance confirmation | The identified reviewer checked conditions for this version. |
Record example: “Goal: the recipient sees price list B for services A, B and C on the page identified in the task. Source: approved version B. Acceptance: review of the six card conditions by the person agreed with the client. Outside scope: a new calculator and changes to other services. Resolve ambiguity before publication.”
This record does not prove the conditions are already met. It establishes a reference for the later review. Do not mark criteria completed when writing them.
If the input is still unapproved, the card can be a proposal but not a ready publication basis. Its wording cannot supply a missing decision about the actual prices.
Check cases that reveal work only appearing complete
A table can be correct on a computer while cutting off the last amount digit on a phone. The recipient gets a different outcome. If the mobile view belongs to the agreed scope, record that condition before implementation. Website usability testing covers observing these issues through actual use rather than assuming a desktop check is sufficient.
Another case is an updated table with a link still opening an old PDF. If the document update belongs to scope, give it a separate criterion. Avoid combining several outcomes into “the price list works”. Separate conditions identify which part needs more work and prevent one successful check from concealing an unrelated unfinished result.
If two input versions contain different amounts, do not choose by assumption. Obtain the version decision and update the criteria. Precise wording cannot repair unapproved data.
Identify which uncertainty stops work and who can resolve it. An apparently complete card is not usable until its source is clear to everyone involved.
Do not add dozens of hypothetical exceptions to a simple task. Choose cases arising from actual use and project boundaries.
A condition should prevent a specific misunderstanding rather than become an encyclopaedia of the entire product. An oversized list can bury the main acceptance requirement and make review less focused.
Identify the reviewer and what their reply establishes
The performer can check their work, but acceptance may belong to someone else. Establish that in the project process. “Link sent for review” means material was delivered, not accepted.
“No comments received” is not automatic confirmation either unless such a rule was actually agreed. Record the review stage separately from sending the invitation.
The reviewer should refer to criteria instead of merely saying “looks good”. For example: “New amounts and the B link confirmed; the mobile table still cuts off service C.” That gives the performer a particular remaining action. Do not reduce a partial outcome to one green status that conceals the unresolved condition.
If a new idea appears during review, identify it separately. It may deserve implementation without proving failure against the existing scope. Client changes to project scope explains recording that decision before adding work. Comparing the idea with agreed conditions helps choose the appropriate next route.
Keep conditions with the task and preserve changed agreements
In Meetlead Projects, task descriptions and comments preserve conditions and later agreements. Owner, status and links retain context. You need an account, website, appropriate permissions, active Projects installation and a plan providing access. The team writes criteria and performs their checks; recording a condition is not an automated assessment.
This is not an automatic testing system or client acceptance-signing portal. Status alone does not prove conditions are met. Record the actual review result in the description or a comment according to team process. Do not promise an approval feature that this record does not provide, even when a task is associated with the customer conversation.
- Criteria describe an outcome for the recipient.
- The input source and change location are unambiguous.
- Each condition has an observable verification.
- Relevant exceptions remain within the agreed scope.
- The reviewer is identified.
- A new idea is separate from a mismatch.
When conditions are difficult to express clearly
Must criteria contain numbers? No. “The link opens the approved file” is verifiable without a percentage.
A number helps only when it describes the needed outcome and has an agreed basis. Do not invent a performance threshold solely to make an ordinary content task seem measurable.
Can criteria change during work? Yes, after clarifying the new agreement and its effect. Preserve the change instead of silently replacing the source.
The team should know which condition version it implements. A changed price file may alter the expected result even if the task title stays identical.
Does every review idea prevent completion? Not automatically. Compare it with the agreed outcome. A mismatch needs correction; a separate need requires a scope decision.
Keep these types of work distinct so a completed agreed result can be recognised while another proposal is considered on its own merits.
Atlassian describes criteria as verifiable outcome conditions rather than implementation instructions. The price-list card is our own example: writing acceptance criteria.
