Ask Your Dev Team about acceptance criteria

Acceptance criteria describe the observable conditions a piece of software must meet before you call it done. Write them before development starts, while changing a sentence is still cheaper than rebuilding a feature.

They don’t need to prescribe the technical solution. They need to make the expected result clear enough for you, the developer, and the tester to recognize the same outcome.

Turn a request into something observable

“Customers can update their address” sounds clear until the team starts asking questions.

Can they update both billing and shipping addresses? Which countries are supported? Does changing an address affect an order already in progress? What happens when a postal code is invalid? Does the customer receive confirmation?

Useful acceptance criteria turn those decisions into statements someone can verify:

• A signed-in customer can edit the shipping address saved to their profile.
• The form identifies required fields before it can be submitted.
• An unsupported postal code produces a clear error and preserves the customer’s entries.
• Changing a saved address doesn’t change an order that has already been placed.

These criteria still leave implementation choices to the development team. They define behavior at the boundary the customer and business care about.

They also don’t need to carry every quality rule in the project. Security checks, browser support, accessibility standards, code review, and documentation may apply to every change. Keep those shared expectations in the team’s broader definition of done, then use acceptance criteria for the behavior specific to this piece of work.

Cover the happy path and the edges that matter

Acceptance criteria shouldn’t attempt to document every possible interaction. An enormous checklist creates the illusion of certainty and can bury the decisions that matter.

Start with the primary successful path. Then add the failures, permissions, data rules, and business exceptions whose misunderstanding would cause meaningful rework or risk.

For a refund feature, the important edges might include who can issue one, the maximum amount, what happens after settlement, and what record appears in reporting. Button color probably belongs in the approved design rather than repeated in every criterion.

Your developer should help find these edges. You know the policy and customer context. They know where software commonly needs a decision. Acceptance criteria are one place those perspectives meet.

Use criteria to review, not merely to start

Criteria lose value when they’re written at planning time and ignored at delivery. They should guide development, testing, demonstration, and approval.

When the feature is ready, review it against the agreed conditions. If a condition isn’t met, the work hasn’t met that criterion yet. If you ask for a new behavior that wasn’t included, it may be new scope rather than a defect. Check the broader requirements and agreement before deciding.

This distinction makes conversations less personal. Instead of debating whether something “feels finished,” you can compare what was delivered with what everyone agreed to observe. If the criteria change, record the change and its effect using the process from issue 25 on change orders.

What strong collaboration sounds like

Try asking:

“Can we read these criteria together and describe how we’ll verify each one?”

“Which business rule is still ambiguous?”

“What failure or edge case would be expensive to discover after launch?”

“Which quality requirements apply to every change, even when they aren’t repeated here?”

A strong developer won’t expect you to author perfect technical requirements alone. They’ll ask questions, identify missing decisions, and translate the final agreement into testable behavior.

Be cautious when criteria merely repeat the feature title, arrive after the code, or contain words like “easy,” “fast,” and “intuitive” without a shared definition. Those words describe an aspiration, not an observable finish line.

Good acceptance criteria create a fair agreement. The team knows what to build, and you know what evidence to expect. That clarity matters whether your developer is Cuttlesoft or another partner.

Go build something and expect better from your developer.