Key takeaways
- A requirement that cannot be tested cannot be estimated, built to or signed off. The ambiguity moves downstream, where it costs more.
- Five warning signs: vague adjectives, no actor, no failure case, hidden dependencies and no measure of done.
- Acceptance criteria written as examples — Given, When, Then — turn opinions into checks.
- A readiness check before planning stops vague work from entering a sprint.
- AI can draft criteria and name the gaps. A person still decides what the business actually wants.
Why it matters more than it looks
When a requirement is vague, every later step quietly fills the gap in a different way. The estimate assumes one thing, the developer builds another, the tester checks a third, and the business discovers the difference at sign-off. None of those steps removes the ambiguity. Each one just pays for it, at a higher price than the one before.
Five signs a requirement cannot be tested
- Vague adjectives: “fast”, “user-friendly”, “secure”, with no number or condition attached.
- No actor: it says what happens, but not to whom or by whom.
- No failure case: the happy path is described; what happens when the card is declined is not.
- Hidden dependencies: it relies on another team, system or decision that nobody has named.
- No measure of done: there is no observable outcome that would settle whether it works.
Rewrite it as examples
The most reliable fix is to write acceptance criteria as concrete examples, in the Given–When–Then form that behaviour-driven development made common. An example is either true of the software or it is not, which is exactly what a tester, a developer and a product owner need to agree on.
| Before | After |
|---|---|
| Exports should be fast | Given an admin exports up to 100,000 audit events, when the export starts, then the file is ready within 60 seconds |
| Only the right people can approve | Given a user without the approver role, when they open a pending change, then no Approve action is shown and the attempt is logged |
| Handle payment failures gracefully | Given a declined card, when the customer pays, then the order stays unpaid, the decline reason is shown and no confirmation email is sent |
Check readiness before planning, not during the sprint
A short definition of ready, applied before an item can be planned, catches most of these problems while they are still cheap. The INVEST checklist — independent, negotiable, valuable, estimable, small, testable — is a good base. In practice teams add:
- An actor is named for every behaviour.
- Acceptance criteria are written as examples, including at least one failure case.
- Dependencies are named, each with an owner.
- Non-functional needs are stated as numbers: response time, volume, availability.
- The item is small enough to finish within a sprint.
Where AI helps, and where it must not decide
AI is good at the mechanical half of this work: spotting a missing actor, proposing the failure cases nobody wrote, drafting criteria in a consistent form, and finding a similar story already in the backlog. It should not decide what the business wants. The pattern that works is a proposal with the gaps named, which the product owner approves, changes or rejects.