Why the format exists at all
The As a / I want / So that structure is not ceremony. It forces three pieces of information that tickets routinely omit: who this is for, what they are trying to do, and why it matters to them. A ticket missing any of the three pushes the guessing onto whoever picks it up.
The role matters because software behaves differently for different people, and a story written for an unspecified user tends to get built for the developer's mental model of an average one. Naming the role — a returning customer, a first-time visitor, an administrator — frequently changes the design.
The want should describe a goal, not an implementation. "I want a dropdown of saved addresses" specifies a solution; "I want to reuse an address I have entered before" describes the need, and leaves room for a better answer than a dropdown.
The clause everybody drops
The "so that" is skipped more than any other part, and it is the one that changes outcomes. It converts a feature request into a problem statement, which is the difference between a team that builds what was asked for and one that solves what was needed.
It also gives you the means to say no well. A story whose stated outcome is already achieved another way can be closed with a reason rather than a judgement, and a story that cannot articulate an outcome at all has just told you something important about itself.
When you cannot write the clause, that is the signal to go and ask. Someone requested this for a reason; if nobody in the room can state it, the requirement is not yet understood well enough to build.
Acceptance criteria that a tester can use
Given-When-Then works because each part has a job. Given fixes the starting state, When names a single specific action, and Then states an observable result. Anything that fails to fit the shape is usually vague in a way that would have caused an argument at review.
The test of a good criterion is whether a tester can tell unambiguously whether it passed. "The page should be fast" fails. "Given a basket of fifty items, when I open checkout, then the total renders within two seconds" passes, and it also surfaces a performance requirement that would otherwise have gone unstated.
Three to seven scenarios is the usual range. If you find yourself writing fifteen, the story is several stories, and splitting it will make estimating, reviewing and testing all easier.
Where stories stop being the right tool
Not everything is a user story, and forcing everything into the format produces some memorably absurd tickets. Infrastructure work, dependency upgrades, refactoring and spikes have no user-facing want, and writing "as a developer I want to upgrade the framework" adds nothing but a costume.
Bugs are not stories either. A defect has a reproduction, an expected result and an actual result, which is a different shape entirely and is served better by a bug report.
The useful rule is to use the format where it earns its keep — work whose value depends on who it is for and why — and to write plainly everywhere else. A team that recognises the difference writes better tickets than one applying the template universally.