I really like this formulation from Mike Cohn’s blog:
As a <type of user>, I want <some goal> so that <some reason>.
It’s a great way to formulate a requirement. But I don’t like the name “user story” as applied to it. Why? Because it’s not a story. It’s one plot point in a story. I realize that the Agile $entity came up with (or at least popularized) the idea of user stories, but I’m a semantic hair splitter.
I don’t want to take something that’s already been named and give it a different, less widely accepted name — or take a widely accepted usage of a name and use it to describe something else. So what do I call the something else, the actual “story” that described the user interaction, from which a number of requirements can be derived. I’m talking about the narrative that describes one user doing a series of tasks, not a formal use case.
The who/what/why of the “user story” described by Cohn is more of an individual requirement, but I think of requirement as something different. Maybe just something more formal. I don’t want there to be the barrier to writing user stories of needing to know the template.
A story should have characters, plot, and resolution. Not roles, reasons, and acceptance criteria. But if I call a story a story then what would I call a “user story”?
Here are some links about user stories: