Writing Acceptable Acceptance Criteria

Teresa Torres argues that acceptance criteria are often the missing piece of a user story, and that they determine when a story is ready for release. She contends that criteria should be written from the end-user's perspective and drafted before implementation, so they capture intended user behavior rather than what engineering happened to build. She recommends making usability measurable with quantifiable thresholds, enumerating error cases to surface hidden assumptions, and defining both performance and stress-test limits. Because criteria are a conversation starter, the product manager should lean on engineering for technical detail while holding the customer's benefit as the standard.

01Key takeaways

• Write acceptance criteria as part of the user story, not as an afterthought after development begins.
• Draft and review criteria before implementation so they reflect user intent rather than engineering reality.
• Replace vague usability goals with quantifiable measures and explicit acceptable thresholds.
• Enumerate error cases such as missing data, out-of-order steps, and abandoned sessions to surface hidden assumptions.
• Define separate thresholds for individual-user performance and system-wide stress behavior.
• Use criteria as a conversation with engineering while keeping the customer's benefit as the validating test.

02Key sections

Missing criteria

Many teams write user stories but neglect acceptance criteria, which define when a story is ready for release. Good criteria are worth the effort because they raise product quality.

Stay in the user's perspective

Criteria should be drafted from the end-user's view before building starts, since engineering-led criteria tend to verify what was built rather than what users need.

Measure usability

Vague demands like 'easy to use' are not testable. Define quantifiable measures such as success rate or time to completion, with acceptable thresholds.

Handle error cases

Listing missing data, out-of-order actions, and interrupted sessions exposes assumptions about needed data and how users should recover.

Performance and stress thresholds

Performance covers individual-user experience like load speed and responsiveness, while stress tests cover system behavior under heavy load. Both need defined thresholds.

Collaborate with engineering

Product managers should partner with engineers on criteria but keep the focus on the end-user benefit rather than getting lost in technical detail.

03From the post

“You've written your user stories, engineers have accepted them, development is in progress. Now what? More often than not, odds are you left off one of the most important parts of a user story - the acceptance criteria. Acceptance criteria tells you when a user story is ready for release.”

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.