The decision that matters
Describe behavior at the boundary of the system. “Make invoices better” does not tell a reviewer what to inspect. “An authorized customer can view their invoice total, due date and payment instructions” does. Include meaningful negative cases: a customer from another account cannot open the same record, and a failed send remains retryable. Avoid prescribing internal function names unless the task is specifically about architecture.
A practical scenario
For an invitation flow, define what happens when a valid email is entered, when that email already belongs to a member and when delivery fails. Then specify what the recipient should see after opening the link. This reveals whether account creation and app access were mistakenly treated as the same operation. A screenshot of the form alone cannot demonstrate that the invitation works.
Before you ship
- Write criteria as observable user or system behavior.
- Include an unauthorized actor and an interrupted operation.
- Keep evidence such as a test result or review note beside the task.
A useful next step
Take one ambiguous task from the backlog and rewrite it with three checks: successful completion, a recoverable failure and an access boundary. Ask someone who did not write the task to review it. Their questions expose assumptions that would otherwise become rework.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.