Why Given/When/Then
Given/When/Then (the Gherkin format popularized by Behavior-Driven Development) separates a scenario into starting state, action, and expected result - a structure that maps directly onto a test case, which is exactly the point. Acceptance criteria written this way tell the team what "done" means before anyone starts building, not after a PR is already open.
What good criteria look like
Each scenario should describe one behavior, not a checklist of unrelated conditions crammed into one Given/When/Then. A story usually needs 2-4 scenarios: the happy path, plus the edge cases that actually matter (an empty state, a permission boundary, an error condition). More than that is often a sign the story itself should be split.
Using the result
Paste the generated scenarios directly into the story before estimation - a story with clear acceptance criteria is dramatically faster to size accurately than one where the team is still negotiating what "done" means mid-vote.