Choose a project type, copy a starting set, and replace the placeholders with the conditions both sides will use to decide whether the work passes.
A useful acceptance criterion names an observable outcome, an objective pass condition, the evidence to inspect, who reviews it, how long review takes, and what happens if it fails. “Works as expected” and “to the client’s satisfaction” do not meet that standard.
| Part | Question it answers | Example |
|---|---|---|
| Outcome | What user or business result exists? | A buyer can submit a valid lead form. |
| Pass condition | What observable state counts as success? | One record is saved and one confirmation is sent. |
| Test context | Under which data, role, device, or environment? | Buyer-role account on the agreed staging build. |
| Evidence | What proves the result? | Submission record, message, and test log. |
| Decision owner | Who can accept or reject? | Named buyer product owner. |
| Review path | By when, and what happens if it fails? | Five business days; fix and resubmit against the failed item. |
This structure is Ratly32’s practical synthesis. It builds on official guidance that acceptance criteria should represent outcomes and support evidence, that work should be assessed against measurable standards, and that software deliverables should have explicit delivery and acceptance terms. The exact commercial effect still depends on the signed agreement and local law.
Editable starter library
Pages, forms, content management, analytics, and handover.
Pass conditionEvery template listed in the scope renders without horizontal overflow at the agreed mobile, tablet, and desktop widths.
EvidenceStaging links plus screenshots or an agreed browser test report for every template and viewport.
Pass conditionA valid submission is stored in the named destination and sends the agreed confirmation; invalid required fields show a useful error.
EvidenceTest submissions, destination records, confirmation message, and error-state recording.
Pass conditionA buyer editor can create, edit, preview, publish, and unpublish the agreed content types without developer access.
EvidenceRecorded walkthrough using a buyer-role account and a published sample item.
Pass conditionThe agreed events appear in the named analytics property, and consent behavior matches the approved specification in target regions.
EvidenceDebug-view captures, event list, and consent-state test results.
Pass conditionThe buyer controls the production domain, hosting, CMS owner account, analytics property, and documented recovery path.
EvidenceAccess checklist signed by the buyer plus current handover documentation.
Roles, core behavior, failure states, performance, and auditability.
Pass conditionEach named role can perform only the actions listed for that role; unauthenticated and unauthorized attempts are denied.
EvidenceRole matrix plus passing tests for allowed and denied paths.
Pass conditionStarting from the agreed state, the target user can complete the named workflow and see the expected saved result.
EvidenceRepeatable test script, screen recording, and resulting database or application record.
Pass conditionEvery agreed invalid, empty, timeout, and duplicate state preserves user data where specified and presents the approved next action.
EvidenceTest cases covering each state with expected and actual results.
Pass conditionThe feature meets the agreed response-time and reliability targets under the documented test data, load, region, and environment.
EvidenceTimestamped performance report with configuration, sample size, percentile, and failures.
Pass conditionThe agreed material actions record actor, action, timestamp, object, and outcome without exposing prohibited sensitive values.
EvidenceSample audit records for success and failure plus retention and access settings.
Catalog, totals, payment states, inventory, and order communication.
Pass conditionFor the agreed test basket, item price, discount, shipping, tax, currency, and final total match the approved calculation rules.
EvidenceCalculation worksheet and matching cart, checkout, and order records.
Pass conditionApproved, declined, canceled, duplicated, and delayed test payments produce the agreed order state without duplicate capture.
EvidencePayment-provider test records mapped to application order records.
Pass conditionStock changes follow the agreed reservation and release rules across checkout, cancellation, refund, and concurrent purchase tests.
EvidenceBefore-and-after inventory records for every defined scenario.
Pass conditionThe buyer receives each agreed message once, with the correct order, amount, locale, sender, and support path.
EvidenceDelivered test messages and provider logs for the agreed lifecycle states.
Pass conditionAn authorized store operator can complete the agreed catalog, fulfillment, cancellation, and refund actions without developer access.
EvidenceBuyer-role walkthrough and resulting platform records.
Contract, identity, retries, errors, observability, and limits.
Pass conditionEvery in-scope operation accepts and returns the approved fields, types, required values, status codes, and version identifier.
EvidenceVersioned API specification plus passing contract tests.
Pass conditionValid credentials receive only the agreed access; missing, expired, revoked, and underprivileged credentials are rejected as specified.
EvidenceSecurity test results for each credential and permission state.
Pass conditionRetrying each named write operation under the agreed duplicate and timeout scenarios does not create an unintended second effect.
EvidenceIdempotency or reconciliation test records showing one final state.
Pass conditionValidation, dependency, timeout, and rate-limit failures return the agreed machine-readable code and safe diagnostic detail.
EvidenceNegative test suite and representative sanitized logs.
Pass conditionThe agreed availability, latency, error, and queue signals are measurable and trigger the named alert path at the approved threshold.
EvidenceDashboard link and a recorded or logged alert test.
Input boundaries, benchmark, human fallback, privacy, and monitoring.
Pass conditionAccepted formats, required fields, size limits, prohibited data, and the behavior for invalid or partial input match the approved specification.
EvidencePassing valid, boundary, invalid, and prohibited-input tests.
Pass conditionThe frozen, versioned evaluation set meets the agreed quality measures and thresholds for each documented user segment.
EvidenceEvaluation-set version, method, per-segment results, and known failure cases.
Pass conditionLow-confidence, prohibited, or exception cases follow the agreed block, escalation, review, and user-notification path.
EvidenceScenario tests showing the decision, reviewer queue, and user-visible state.
Pass conditionCollection, access, retention, deletion, and provider use of in-scope data match the documented buyer-approved rules.
EvidenceConfiguration captures, access test, deletion test, and provider settings.
Pass conditionThe agreed input, output, error, cost, latency, and quality signals are recorded without retaining prohibited content.
EvidenceMonitoring view plus a tested alert or review trigger for an agreed failure condition.
Inventory, reconciliation, interruption, rollback, and buyer control.
Pass conditionEvery in-scope source, object type, field mapping, transformation, exclusion, and owner appears in the approved inventory.
EvidenceSigned inventory and mapping document with source counts.
Pass conditionPost-migration counts and agreed field-level samples match the source after documented transformations and approved exceptions.
EvidenceAutomated reconciliation report and exception register.
Pass conditionThe cutover completes within the agreed service window and all named critical user paths pass before service reopens.
EvidenceTimestamped cutover log and critical-path smoke-test results.
Pass conditionBefore the point of no return, the team can restore the approved source state within the agreed recovery window using the documented procedure.
EvidenceSuccessful rehearsal record, backup verification, and named rollback decision owner.
Pass conditionThe buyer can access and administer every agreed repository, environment, account, secret store, data export, and operating document.
EvidenceBuyer-performed access test and signed handover checklist.
These are editable examples, not universal requirements. Agree the targets, test environment, reviewer, review window, and failure path for the specific deal. Nothing is uploaded when you switch categories or copy a template.
| Weak wording | What is still missing | Better direction |
|---|---|---|
| “The page loads quickly.” | Metric, percentile, data, device, region, and test method. | Name a target and the exact test environment. |
| “The integration works.” | Operations, inputs, outputs, failure states, and proof. | List contract tests for each in-scope operation. |
| “The design is responsive.” | Templates, widths, browsers, and unacceptable defects. | Test the listed templates at agreed viewports. |
| “AI results are accurate.” | Evaluation set, measure, segment, threshold, and exceptions. | Freeze a versioned benchmark and document failures. |
| “The client will approve.” | Reviewer, decision window, reasons for rejection, and resubmission. | Name the decision process before delivery. |
Acceptance criteria test whether a specific deliverable meets the agreed user or buyer outcome. A definition of done is the team’s reusable quality floor—for example, required review, documentation, testing, and deployability. A milestone may need to satisfy both. Atlassian and Agile Alliance make the same distinction in their official explanations.
Attach acceptance to each paid milestone. A contract-level promise cannot rescue a deliverable that nobody knows how to test.
If the proposal does not name the deliverables cleanly yet, start with the free software proposal analyzer. If it does, move the chosen criteria into the Deal Spec builder.
Software acceptance criteria are the observable conditions a deliverable must satisfy before a named reviewer accepts it. Good criteria describe the outcome, pass condition, evidence, reviewer, review window, and failure path.
The buyer and provider should agree them together before work begins. The buyer contributes the needed outcome and operating context; the provider and testers contribute feasibility, edge cases, and a repeatable verification method.
No. Acceptance criteria are specific to one feature or deliverable. A definition of done is a broader team-wide quality standard that may apply to every increment.
There is no universal number. Use the smallest set that covers the material user outcome and the costly failure states. If the list becomes hard to review, split the milestone.
Yes, but the change should be explicit. Record what changed, why, whether price or timing changes, and which version both sides will use for acceptance.
No. Given–When–Then is useful for behavioral scenarios. A decision table, checklist, benchmark, reconciliation rule, or test matrix may be clearer for performance, migration, security, or operational work.
Yes. Name the applicable version, scope, test environment, method, threshold, and evidence. Referencing a standard alone does not prove conformance.
Next move
Build a local Deal Spec with milestones, evidence, review terms, and the unresolved questions from your proposal.
