The Cost of Thin Acceptance Criteria (and a Free Tool for Writing Better Ones)
Acceptance criteria are the least glamorous artifact in product management. Nobody puts them in a portfolio. Nobody gets praised in a retro for writing thorough ones. And that’s exactly why so many teams write them badly.
Here’s the pattern, if you’ve been in enough sprint planning sessions: a feature gets scoped, the engineering estimate comes in, everyone’s ready to move on, and the acceptance criteria gets written in the last five minutes as a formality. “User can reset their password.” Done. Ticket moves to the board.
Then three weeks later, QA finds that the reset flow doesn’t handle an expired token gracefully. Or a customer reports that they got locked out because the rate limiter kicked in with no explanation. Or the error state for “email service is down” was never defined, so it just fails silently. None of this was a coding mistake. It was a criteria mistake, made weeks earlier, in a rush, by someone who knew better but didn’t have the ten extra minutes.
Thin acceptance criteria don’t fail loudly. They fail quietly, in production, usually at the worst time, and they get blamed on engineering when the real gap was upstream.
What separates thorough from thin
Good acceptance criteria do three things that a one-line description never does:
They specify behavior, not just outcome. “User can reset password” is an outcome. “Given a user requests a password reset, when they submit a valid email, then a reset link is sent and expires in 30 minutes” is a behavior that’s testable, and an engineer can build directly against it without guessing your intent.
They cover the non-functional requirements nobody enjoys thinking about. What happens under load? What’s the error state when a dependency is down? What’s the timeout? These aren’t edge cases, they’re day-one production realities, and if they’re not written down, someone is inventing the answer at 2am during an incident instead of during planning.
They name the edge cases before they become bugs. What happens if the user clicks the reset link twice? What if the token is already expired? What if they’re on their third failed attempt? A team that names these during refinement ships fewer surprises. A team that discovers them in QA ships the same features slower, angrier, and later.
None of this is complicated. It’s just tedious, and tedious work is the first thing that gets cut when a sprint is behind.
A tool to make thorough the default, not the exception
We built a free tool that takes a rough feature description and drafts what a thorough set of acceptance criteria actually looks like: a proper user story, Given/When/Then scenarios, the non-functional requirements teams typically skip, and the edge cases that tend to surface as production incidents instead of planning conversations.
It’s built on the Claude API, not a custom model, not proprietary AI, just a well-built application of an existing tool aimed at a specific, unglamorous problem. You describe a feature in plain language, and it gives you a structured draft in seconds. Three detail levels are available depending on how much rigor the feature warrants: Focused, Thorough, and Rigorous.
Here’s what that looks like on a real feature, a notification center:
Feature described (plain language): “A notification center that shows users system alerts, machine events, and ownership verification updates so they don’t miss anything important.”
What the tool generated:
User Story
As a platform user, I want a centralized notification center that surfaces system alerts, machine-related events, and ownership verification updates, so that I can stay informed and take timely action without missing critical information.
Acceptance Criteria (a selection)
- Real-time system alert: Given a maintenance window is scheduled by an administrator, when the system broadcasts the alert, then all active users receive it within 5 seconds under the System category with Warning severity, and the unread badge increments by 1.
- Machine error notification: Given a machine assigned to the user enters an error state, when the backend detects the status change, then a Critical notification is created containing the machine ID, name, previous state, new state, and a deep link to the machine detail page.
- Ownership verification deadline: Given a user submits an ownership transfer request, when the recipient hasn’t verified identity within 24 hours, then they receive a Warning notification with a deadline timestamp and a “Verify Now” CTA to the verification flow.
- Mark all as read: Given multiple unread notifications, when the user clicks “Mark All as Read,” then all are marked read, the badge disappears, and the state persists across page refreshes.
Non-Functional Requirements (a selection)
- Real-time delivery under 5 seconds for Critical and Warning notifications at up to 10,000 concurrent users.
- First page of notifications returns in under 300ms at the 95th percentile.
- Fully accessible per WCAG 2.1 AA: keyboard-navigable, screen-reader compatible, sufficient contrast on severity badges.
- Ownership-verification data handled per GDPR/CCPA retention policy; encrypted in transit (TLS 1.2+) and at rest.
Edge Cases (a selection)
- Zero notifications → empty state: “You’re all caught up!” with no unread badge.
- WebSocket connection drops → client falls back to polling every 30 seconds with a subtle “Reconnecting…” indicator, so nothing is silently lost.
- Machine deleted while a related notification exists → the deep link redirects to a “Machine no longer available” page rather than a 404.
- Duplicate events for the same machine and state within a 10-second window → deduplicated into a single notification.
That’s a trimmed sample. For this one feature, the tool generated 10 Given/When/Then scenarios, 8 non-functional requirements, and 10 edge cases in a few seconds.
That’s a draft, not a final answer. The tool doesn’t know your users, your architecture, or your specific constraints; you still own the judgment call on what’s actually right for your product. What it does is remove the blank-page problem and the last-five-minutes rush, so the starting point for your criteria is thorough instead of thin, and your job shifts from generating from scratch to reviewing and correcting.
Try it
The Acceptance Criteria Writer is free, with no signup required: clarushorizon.com/acceptance-criteria-writer
Run it against a feature you’re scoping this week, ideally something with a few non-obvious edge cases and see where it gets you further, and where it still needs your judgment. That gap between the two is exactly where a PM’s real value sits.
Leave a Comment