User stories and acceptance criteria
In Agile, requirements are written as short user stories focused on the user and the benefit:
As a [role], I want [goal], so that [benefit].
Your story
As a student, I want to pay from my phone so that I don't have to queue.
- ✓ Has a clear role
- ✓ Has a goal
- ✓ States a benefit (Valuable)
- ✓ Goal is short and focused (Small)
- ✓ Focuses on the goal, not a technical solution
Each story has acceptance criteria that define when it's done. The most common format is Given / When / Then:
Givena student has an order in “Waiting” status
Whenthey tap “Cancel order”
Thenthe order becomes “Cancelled” and the amount is refunded within 3 working days
| Independent | As independent of others as possible |
| Negotiable | Open to discussion, not a rigid contract |
| Valuable | Clearly valuable to the user |
| Estimable | The team can estimate its size |
| Small | Small enough for one sprint |
| Testable | Testable through acceptance criteria |
Watch outThe first letters spell INVEST, a checklist for story quality. To prioritise, use MoSCoW: Must, Should, Could, Won't (this time).