Writing acceptance criteria that survive sprint planning
A practical pattern for criteria that stay useful when engineers start slicing work—and when stakeholders change their minds mid-sprint.
Acceptance criteria often fail for a simple reason: they describe a wish, not a checkable outcome. In Toolkitbranch studios we ask learners to write criteria as observable states a tester or peer could verify without asking the author for clarification.
Start from the user-visible change, name the preconditions, and keep each criterion independent. Bundling five behaviours into one line invites partial delivery that still “passes” the ticket.
When stakeholders revise scope, treat criteria as the negotiation surface. Updating the criterion list is cheaper than rewriting a vague paragraph buried in a ticket description.
In our Requirements Analysis Studio, teams practise converting a messy brief into five to eight criteria, then defend those lines in a simulated planning conversation.