What needs to be finished first
User stories exist in a coarse-grained form (title, description, user value) but are not yet implementation ready.
What needs to be ready before start
Whiteboard or Miro board with columns per story; story cards or tickets visible; Given-When-Then template as a banner; pens; timer; Definition of Done as a reference.
One facilitator (PO, Scrum Master, or BA); Product Owner for scope; at least one engineer; one tester for edge cases; optionally a domain expert for deeper subject matter.
Story descriptions with user value; known constraints (performance, compliance, browser support); Definition of Done; similar existing stories as reference.
20-40 min per story
One section per story on the board. Given-When-Then template visible. Definition of Done in the sidebar. Rule: no vague criteria (fast, simple, beautiful). Concrete, testable statements only.
The one question this method answers
Which concrete, testable criteria describe the happy path, edge cases, and negative paths of this story so clearly that all three roles share the same Definition of Done?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Fix the story summary | 3-5 min | Put the story as title and user-value sentence on the wall. Clarify scope questions. PO confirms understanding. | If scope is still unclear after 5 min, send the story back to Discovery. Acceptance criteria without scope agreement are useless. |
2Phase 2: Happy-path criteria | 5-10 min | Create Given-When-Then for the standard case. Concrete input values and observable output. At least 2-3 criteria per story. | Reject vague criteria such as 'works' or 'intuitive'. For each criterion, a test question must be possible: 'How would I verify this?' |
3Phase 3: Edge cases and special cases | 5-15 min | Tester drives edge-case search: null values, max values, empty input, parallel actions. Separate criterion for each edge case. | If no edge cases emerge, the story is understood too superficially. At least 30% of the criteria should cover edge cases. |
4Phase 4: Negative paths and error cases | 5-10 min | What happens with invalid input, missing permission, or external failure? State the expected error message or system response as a criterion. | Negative paths are often forgotten. The PO decides whether the error case belongs in the story or as a separate story. Both are valid, but must be deliberate. |
5Phase 5: Review and transfer | 3-5 min | Read the criteria aloud. Engineer and tester confirm implementability and testability. Transfer the criteria into the story tool. | Reading aloud exposes ambiguities. If roles disagree, clarify immediately instead of carrying it into the sprint. |
What comes out at the end
Acceptance criteria in the story tool (Jira, Linear, GitHub) in Given-When-Then format or as a bullet list. Typically 4-10 criteria per story. Edge cases marked. Linked with Definition of Done.
Criteria versioned as part of the story. If changed after sprint start, note the reason in the story comment. Keep criteria templates per domain in the wiki and review every 3-6 months.
Compact working template for Acceptance Criteria Workshop with context, input, output artifacts, and next step.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Story: As a tax advisor, I want to export my customer list as CSV so I can import it into DATEV.
Acceptance criteria (Given-When-Then)
Happy path
Edge cases 4. Given Sabine has 0 customers, when she clicks 'Export CSV', then a CSV with only the header row is downloaded and an info toast appears saying 'No customers exported'. 5. Given Sabine has more than 10,000 customers, when she clicks 'Export CSV', then the export starts asynchronously and she receives an email with a download link within 10 min. 6. Given customer names contain commas or quotation marks, when the CSV is generated, then fields are escaped correctly according to RFC 4180.
Negative paths 7. Given Sabine does not have permission to 'Manage customers', when she clicks 'Export CSV', then the button is not shown. 8. Given the backend is unavailable, when Sabine clicks 'Export CSV', then the error message 'Export currently unavailable, please try again later' appears without a browser crash.
Recognize symptoms and steer against them
Criteria such as 'works smoothly', 'user-friendly', or 'fast enough' land in the story.
Make it concrete: 'works' -> 'loads in <2 s'; 'user-friendly' -> 'completes the task in <3 clicks'. If you cannot become concrete, the requirement is not understood.
All criteria cover the standard case, but edge cases and negative paths are missing.
Rule of thumb: at least 30% edge cases. The tester actively drives them. Keep a checklist of typical edge patterns (null, max, empty, permission, error) as a trigger.
Only PO and engineer work on the criteria, so edge cases stay thin.
Use the Three Amigos principle. If the tester is unavailable, move the workshop or add an asynchronous tester review before sprint start.
The PO adds criteria after sprint start and the engineer feels overwhelmed or betrayed.
Criteria change after sprint start equals scope change. Move the item out of the sprint or create a new story for the extension. Communicate the rule clearly.
The criteria cover story logic, but cross-cutting requirements (tests, docs, accessibility) are missing.
Keep the Definition of Done visible in the workshop sidebar. Check per story whether DoD points were added. Do not repeat generic DoD items per story, but mark the relevant ones.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.