What defines a user story? The typical answer to this is syntax. As long as you have written something that is formatted “As a… I want a… in order that” (or “Given… When… Then” if you use BDD) then it’s a user story. I’d like to suggest that syntax isn’t a good definition.
The clue is in the name: stories. We tell stories because we can assimilate them easily. We tell stories because they help to provide context for a situation. We tell stories because they create shared understanding.
How many times have you told a story and ended up with a different understanding of that story from someone listening? I’m going to guess that it’s not that often. How many times have you read something and ended up with a different understanding of it than someone else who has read the same document? If you’re anything like me, this happens frequently.
We can both write the same thing and understand something radically different from it” – Jeff Patton
The stories, the discussions, the conversations: these are the primary artefact, these are what defines a user story. The syntax, the writing on a card, is the secondary artefact, the recording of just enough detail that people remember the conversation, the narrative, the story.
When [at Snowbird] we were talking about names for agile software development, Kent Beck suggested ‘conversational’, because there should be an ongoing conversation between software developers, business people, and anybody involved in making that customer experience better.” – Martin Fowler
The Key to All Mythologies 
You might remember working in a different way. One where you helped write a list of requirements, and then prioritise them. And then (sorry, icky verb warning) workshopped the list of requirements. And then watched as the requirements grew to a document several hundreds of pages long. And then the requirements weren’t descriptive enough, so you hired another analyst to create use cases, and cross-referenced the use cases to the requirements. And then you created Photoshop versions of what the UI would look like, and cross-referenced those to the use cases and the requirements. And then people didn’t have enough time to read the requirements list that was cross-referenced with the use cases and the Photoshop files, so someone else was asked to do this. And then someone realised it would take 20 years to deliver everything on the list, so there was a shout-off in an airless and soul-less meeting room where everyone deployed every last ounce of passive aggressive political capital they owned in order to make sure that “their” requirements were on the list. And then there was another, secret version of the list that no-one was allowed to see because of the shouting that happened when people could see it. And then the thing got built, and it wasn’t what anyone thought any of the requirements on the list described.
(18f describe an antipattern that they call “Laundry lists of user stories”in this blog post. This says: “Cataloguing is a symptom that the organisation has failed to actually adopt agile principles. It’s effectively nullifying any change from using the same requirements traceability matrix as before.”)
Jeff Patton described this process more succinctly:
everyone hates the document in the end. Yet we still keep trying to create a better one.”
Correct syntax, better documentation, more documentation or even different documentation: none of these are the definition of a user story. If your first reaction to “that user story isn’t good enough” is to write more on the card rather than start a conversation, then ask yourself a simple question. Are you prepared to work towards shared understanding, or would you prefer to carry on hating the document?
 If we were to rewrite Middlemarch for the 21st Century, Casaubon’s “The Key to All Mythologies” would become “A Prioritised Requirements List for a Universal Web Publishing System”.