Acceptance Criteria Made Easy. The D.O.N.E. Checklist

Most software waste is not caused by bad coding; it is caused by vague expectations.

When “done” is fuzzy, work expands. Teams rebuild the same feature two or three times. Stakeholders argue about what was promised. Developers guess. Users get frustrated.

Clear acceptance criteria fix that.

Acceptance criteria are simple statements that define what must be true for a feature to be considered complete. They protect speed, quality, and budget at the same time.

What Acceptance Criteria Are (In Plain English)

Acceptance criteria are the rules that decide if a feature passes.

They are not a long document. They are not technical. They are the shared agreement that prevents confusion.

Good acceptance criteria:

• define outcomes, not opinions
• include edge cases that matter
• explain what happens when things go wrong
• make testing easier and faster

Weak acceptance criteria sound like this:

• “Make it user-friendly.”
• “Improve the report.”
• “Add a better search.”

Those are wishes, not requirements.

The D.O.N.E. Checklist

Use D.O.N.E. to write acceptance criteria quickly.

D . Data Rules Are Defined

State what data is required, optional, and validated.

Examples:

• “Customer email is required and must be valid.”
• “Postal code is optional, but if present must match country format.”
• “Amount cannot be negative.”
• “Status must be one of: New, In Progress, Completed, Archived.”

This prevents silent failures and messy databases.

O . Outcomes Are Measurable

Define what measurable success looks like in plain results.

Examples:

• “A dispatcher can assign a job in under 60 seconds.”
• “Invoice total matches line items including tax rules.”
• “A manager can export the report to CSV.”

Measurable outcomes make reviews and testing faster.

N . No Edge Cases Ignored

List the top edge cases that are common in real work.

Examples:

• duplicate customers
• missing address
• late approvals
• cancelled orders
• partial payments
• two people editing the same record

Edge cases are not rare. They are the daily grind.

E . Expected Errors Are Handled

Define what happens when something fails.

Examples:

• “If integration is down, show a clear message and queue the request.”
• “If a user lacks permission, show Access Denied and log the attempt.”
• “If a required field is missing, highlight it and block save.”

Good error handling is craftsmanship. It makes software calm under pressure.

A Simple Template That Works

Use this structure for each feature:

• Given (starting condition)
• When (the user does the action)
• Then (the result must happen)

Example:

• Given a user with role Billing Clerk
• When they generate an invoice for an order
• Then the invoice total must match the order total using the tax rules, and the PDF must be saved to the customer record

This format keeps writing fast and clear.

How D.O.N.E. Prevents Scope Creep

Scope creep often hides inside “interpretation.”

One person imagines a feature doing 3 things. Another imagines 10 things. Nobody wrote it down, so everyone is “right.”

D.O.N.E. shrinks interpretation.

• Data rules prevent “we forgot that field.”
• Outcomes prevent “this isn’t what we expected.”
• No ignored edge cases prevent “it breaks in real use.”
• Error handling prevents “it fails silently.”

The list becomes the contract for the feature and is signed off in the Statement of Work (SOW).

Mini Case Study. Finance Workflow That Kept Changing

Problem: A finance company built a custom approval workflow for high-value transactions.

The goal was simple. Route approvals to the right people and log the decision.

Mistake: Requirements were discussed verbally and signed off based on a demo. Acceptance criteria were missing. After each sprint, stakeholders asked for “one more small change.” Each change seemed reasonable, but the workflow kept expanding.

Developers rebuilt the same screens repeatedly. Testing got slower. The budget started to drift.

Fix: The team stopped and wrote acceptance criteria using D.O.N.E.

• Data: required fields, audit log fields, approval states
• Outcomes: approval completes in one minute, decision is recorded, report is exportable
• No edge cases ignored: delegation, vacations, rejected approvals, resubmissions
• Errors: missing data messages, permission errors, integration fallback

The criteria were reviewed in a short meeting and then frozen for the next release.

Result: The next sprint shipped cleanly. Review meetings became calm. Stakeholders could request changes, but they went into the backlog as new items, not as hidden expansions. The budget stabilized because “DONE” became real.

Quick Takeaways

• Vague “done” creates rework and conflict.
• Acceptance criteria define what must be true for a feature to pass.
• Use D.O.N.E: Data, Outcomes, No edge cases ignored, Expected errors handled.
• Strong criteria protect speed and quality at the same time.
• If criteria cannot be written clearly, the feature is not ready to build.

Put this to work: Pick your next feature and write 5 to 10 acceptance criteria using D.O.N.E before development starts.