Find ambiguous wording in a user story and turn it into specific decision questions.
Write acceptance examples that expose a rule's boundaries and exceptions before testing the build.
A sentence can read fluently while leaving a tester unable to decide an outcome. ‘As a patient, I want to cancel my booking easily so I can change my plans’ states a need; it does not say when cancellation is allowed, whether a payment is refunded, or what happens after the appointment starts. One tester may assume ‘at least 24 hours ahead’ and another ‘any time on the previous calendar day’. They would then test different products. A good review does not invent policy for the tester. It separates what the need owner said from what the team inferred and asks questions whose answers change the result. The aim is not a long form but removal of ambiguity that affects product behavior.
An acceptance example may use Given/When/Then, but its steps need data that expose the decision. Once the policy is settled as cancellation at least 24 hours before the appointment, including the boundary instant, write: Given a 20 June 09:00 appointment, when its owner requests cancellation at 19 June 09:00, then the booking becomes cancelled and the specified amount is refunded. At 19 June 09:00:01, the request is refused and the booking remains unchanged. These examples discriminate `<` from `<=` at the cutoff and its neighboring second. They do not establish correct handling of all time zones. Add an unauthorized identity example if ownership is part of the rule. The examples make clear which facts to capture: prior and final states, request time, actor identity and amount.
Prioritize review findings by effect. Ambiguity that changes money, authorization or timing needs a decision before implementing behavior or accepting its tests. A naming error that changes no meaning can be corrected editorially. Keep a compact record: original wording, two possible interpretations, an example that distinguishes them, decision owner, adopted rule and affected tests. If no decision arrives, mark the case unresolved instead of silently implementing one interpretation. After the rule is agreed, check fitness for the user's need as well. A rule can be testable but unsuitable; for instance, it may refund less than users understand from ‘the fee’. Clarity against a specification and fitness for use are complementary checks.
Lesson summary
Find ambiguous wording in a user story and turn it into specific decision questions. Write acceptance examples that expose a rule's boundaries and exceptions before testing the build.
