How to Write Acceptance Criteria That Preserve Product Intent

In short

• Acceptance criteria are checkable statements about what work must do. Written before development, they keep the product owner’s intent visible.
• One sentence of intent can support two behaviors. The product owner decides which is meant.
• A short worksheet turns intent into five to seven observable criteria.
• A test built on a wrong assumption can pass without proving the intended outcome.

Acceptance criteria are checkable statements that describe what a piece of work must do before the person who asked for it accepts it. Atlassian’s guide frames them as verifiable conditions for a single feature. Written before development starts, they turn a product owner’s intent into behavior that a developer, a tester and an AI assistant can all observe the same way. Below: how to write acceptance criteria for one request, settle competing readings of it, and keep approved changes visible.

Take a synthetic example, invented for this article. A product owner writes one line on a work item: notify the assigned support owner when a case has had no customer reply for the agreed window. The feature ships and passes its tests. Weeks later, support owners get reminders on cases they parked on purpose, and some get them at night. Engineering built one reasonable reading. The product owner meant another. With AI-assisted development the sentence may go straight into a prompt, so a model fills the missing decisions instead of a colleague. The feature itself needs no AI, and the method below needs no particular tool. Writing intent down this way is also part of JetRuby’s idea-to-production delivery.

Why Product Intent Changes During a Handoff

Intent starts as a conversation, becomes a work item, may become input to an AI assistant, and then becomes code. At each step some context stays behind: who the user is, what the purpose was, which cases the owner had in mind and did not say aloud.

Two kinds of gaps appear. A missing constraint is something the owner knew and did not write, such as “no reminders at night”. An unresolved choice is something nobody has decided, such as whether an out-of-office reply counts as a customer reply. A person who meets either gap guesses. An AI assistant guesses too, usually without flagging it.

The study “Vibe Coding in Product Teams” gives background on the AI side. Its authors interviewed 22 product team members in 2025 about work where people state intent in natural language and a model produces prototypes and code. Participants reported challenges with code reliability and integration. The research is qualitative, covers product teams, and the cited version (v3) is dated 1 May 2026. It does not measure how often delivered work differs from what was asked, and it is not a survey of US product owners. It supports one point: intent often travels as plain text, so what the text leaves out matters.

Five things stay separate. Intent is the outcome the owner wants. An implementation choice is how engineering builds it. A criterion is an observable statement of behavior. Test evidence is the result of checking one. The acceptance decision is a person’s call, after seeing the evidence, that the work meets the intent.

Turn One Product Intent into Observable Behavior

Choosing which need deserves attention is discovery work, covered in business requirements analysis. The worksheet starts after one intent is picked. It is an editorial recommendation for the conversation with engineering and QA, not a product or a verified company standard. The first row follows the habit behind user stories and user story acceptance criteria: tie a person to a goal and the value they expect. A visible purpose lets an engineer judge a case the criteria did not foresee. Window, hours and statuses are example values.

Field	Completed entry
User and purpose	The support owner assigned to a case. Purpose: stop cases from sitting unnoticed once the customer goes quiet, so the owner can follow up or close them.
Expected behavior	When a case has had no customer reply for the agreed window, the assigned owner gets one in-app notification naming the case.
Conditions	Status is "Waiting on customer". The window is the agreed one, say 48 hours in this example, counted from the owner's last message. Notifications arrive between 9 a.m. and 6 p.m. in the owner's profile time zone, and later ones wait for the next 9 a.m.
Exclusions	Other statuses. Closed or merged cases. Cases the owner has paused.
Constraints	Only users who can open the case are notified. The notice carries the case title and a link, with no customer contact details.
Observable evidence	A test case with timestamped messages shows the notification at the stated time and none for each excluded case.
Decision owner	Product owner for behavior. Support lead for window length and working hours.

Separate Constraints from Implementation Preferences

Engineering needs room to choose how to build. The product owner needs certain rules to hold whatever the build looks like. Sorting items into three groups shows who must answer the open ones. System-wide limits sit outside this worksheet, and a software architecture review checklist is a short reference for them.

Item	Type	Who decides
The window counts from the owner's last message.	Constraint	Product owner
The owner's profile time zone sets delivery hours.	Constraint	Product owner
Only users who can open a case are notified.	Constraint	Product owner, with engineering
A scheduled job or an event timer drives reminders.	Implementation preference	Engineering
Whether an out-of-office reply counts as a customer reply.	Open decision	Product owner, with the support lead

Write Acceptance Criteria Before Development Starts

Vague wording sounds fine until someone checks it. “In time” and “reminded” mean nothing until they are tied to a status, a clock and a place. The rewrite makes each line answerable with yes or no by watching the product.

Acceptance Criteria Examples: Before and After

Before. Support owners are reminded when customers do not reply in time.

After.

1. A case in “Waiting on customer” with no customer message since the owner’s last message, for the agreed window, produces one notification to its assigned owner.
2. The notification names the case, links to it and carries no customer contact details.
3. A notification that falls due outside the owner’s working hours arrives when the next working day starts.
4. A case in any other status, or one the owner has paused, produces no notification.
5. A customer reply before the window ends cancels the reminder. The count restarts at the owner’s next message.
6. After the first notification, the same case produces no further one until the owner sends a new message and the window runs out again.
7. A user who cannot open the case receives no notification about it.

Given a case in “Waiting on customer” whose owner was notified at the end of the window.

When a day passes with no customer reply and no new owner message.

Then no second notification is sent.

Review the criteria with engineering and QA before anyone builds. Engineering checks that each line can be built, QA that it can be tested, and the product owner that none hides a business choice. Whether the item is clear enough to start is a separate decision, covered by the Definition of Ready article.

Check Failure and Boundary Cases

• Closed case. A case closed after the window starts produces no notification.
• Reassigned owner. The reminder goes to the current owner, and the window keeps its original start.
• Duplicate notification. A retry does not send two notices for one window.
• Missing permission. An owner who lost access before the reminder sees nothing.
• Changed time setting. The profile time zone at delivery time applies.

Each answer is a decision for the product owner to confirm.

Use AI Without Giving It the Missing Product Decisions

An assistant that writes code from the reminder sentence must choose a clock, an owner and a status filter. It can then write tests from that code, and they check its own choices. A criterion says what the product must do. A test says whether one run did it. If the test rests on a mistaken assumption, it passes and proves nothing about intent. A generated test might assume the owner is whoever created the case, then assert that.

GitHub’s documentation for Copilot inline suggestions says suggested code may not reflect the developer’s intent and that generated tests should be reviewed, since they may not cover all scenarios (GitHub Docs). That describes one product, not every model. The rule travels: people resolve intent first, then review the output.

Assumption a model or engineer may make	Human decision	Verification
The owner is whoever created the case.	The product owner names the current assignee.	A reassignment test case, reviewed by QA.
Any customer message resets the clock.	The product owner and support lead rule on automatic replies.	Written examples, each checked by hand once.

Ask Engineering to Read the Intent Back

Before work starts, ask product, engineering and QA to explain the intended behavior from the worksheet in their own words, separately. Then compare. Prompts:

• What does the owner see at 6 p.m. on a Friday when the window ends over the weekend?
• Which statuses trigger a reminder, and which do not?
• What did you assume that the worksheet does not say?
• QA: what is the first test you would write, and with what data?

A mismatch is a finding about the worksheet. It becomes a visible question with a named owner, not an accusation.

Keep Changes Visible After the Handoff

New information arrives during development. A criterion changes only after a recorded decision. A clarification resolves an ambiguity inside the original intent, such as ruling that out-of-office replies do not count. A scope change adds a new intent, such as escalating to a manager after a second reminder. The first updates the worksheet. The second becomes its own backlog item.

Field	Entry
Original intent	Notify the assigned owner when a case has had no customer reply for the agreed window.
New information	QA found that automatic out-of-office replies would reset the count.
Decision owner	Product owner, with the support lead.
Approved change	Automatic replies do not count as customer replies.
Affected examples	Criterion 5.

Keep the reasoning next to the new wording instead of overwriting the old line. Store the worksheet and change records where the team already keeps current decisions; the software development documentation article describes where those usually live.

Connect the Criteria to the First Accepted Piece

Each criterion should name the evidence the owner will want later, such as a sample case or a timestamped log line. The later decision is covered in the article on human acceptance of AI-generated work. Criteria show that a feature behaves as intended, not that it produces the outcome the owner hoped for. The Scrum.org Evidence-Based Management guide separates shipping a feature from the result users get. Clear criteria make work easier to examine. They do not remove all ambiguity or guarantee commercial success.

Leave the Method with the Product Owner

The method repeats on the next item: the product owner fills in the worksheet, runs the read-back and records changes. A worksheet cannot replace engineering judgment. It puts the owner’s decisions where engineering can see them.

• The worksheet template is saved where the team works.
• Each open decision has a named owner and a date.
• The product owner can explain every criterion unaided.
• Change records sit with the worksheet, with reasons.

Review One Handoff Before Work Starts

For one real backlog item, run this sequence of acceptance criteria best practices.

1. Read the intent. Write one sentence of intent and one of purpose. Read both aloud.
2. Resolve interpretations. List the ways a colleague or an AI assistant could read it. Decide each, or name who will.
3. Check examples. Write five to seven observable criteria and the boundary cases.
4. Name decision owners. Put a name next to every constraint and open decision.
5. Confirm the next action. Agree who starts, with what, and where changes are recorded.

FAQ

What are acceptance criteria, and how do they preserve product intent?

Acceptance criteria are checkable statements about what one piece of work must do. They preserve intent by turning a request into observable behavior, so developers, testers and AI tools read the same expectation. A Definition of Done is different: it is the team’s shared quality bar for all work.

Why can a delivered feature differ from the product owner’s intent?

Intent loses context at each handoff, and none of this requires carelessness. A constraint the owner knew may never be written down, and a choice nobody made gets decided by whoever builds. One sentence can hold two reasonable readings, and the builder picks one.

How can a product owner make intent observable before development?

State the user and the purpose. Describe the expected behavior in terms someone can watch: a status, a time, a notification. Add conditions, exclusions and constraints, then name the evidence that would show it happened. Rewrite any line that cannot be checked by observing the product.

How detailed should acceptance criteria be?

Detailed enough that engineering, QA and the product owner reach the same yes or no on each line. Cover the main behavior, eligibility, exclusions and boundary cases that change business results. Leave implementation choices to engineering. Five to seven criteria per item suit the example here.

Who resolves conflicting interpretations of a requirement?

The product owner resolves readings that change business behavior, such as who is reminded or which statuses qualify. Engineering resolves implementation choices, and QA confirms testability. Nobody should settle a business rule silently. The answer goes into the worksheet with the decider’s name.

Can AI-generated tests prove that the intended behavior was preserved?

No. A generated test checks the assumptions in the code or prompt it came from. If those are wrong, the test can pass while the intended behavior is missing. Generated tests help with coverage but need human review against criteria the product owner wrote first.

What should happen when the intended behavior changes during development?

Record the change before updating any criterion: the original intent, the new information, who decided, the approved change and the examples it touches. Decide whether it clarifies the current intent or adds a new one. A clarification updates the worksheet. A new intent becomes a separate backlog item.

What should stay with the product owner after an outside partner leaves?

The completed worksheets, the criteria for each item, the change records and the list of decisions with their owners. The owner should also keep the read-back habit and explain each criterion unaided. A partner can help set this up, but intent stays the owner’s.