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:

http://blog.mountaingoatsoftware.com/?p=24

http://www.mountaingoatsoftware.com/article_view/27-advantages-of-user-stories-for-requirements

http://c2.com/cgi/wiki?UserStoryDiscussion

http://en.wikipedia.org/wiki/User_stories

http://www.extremeprogramming.org/rules/userstories.html