User stories intent is not to capture requirements completely. We know that written words are not sufficient to capture requirements for two reasons. First there is a lot of knowledge regarding requirements that are very difficult to document and hence to consume. Second a large part of requirements is not visible. It is like an iceberg, what you see is much less than what is hidden.

The point I trying to say is that, we conduct a workshop with users, developers and testers to discuss, model, elaborate on what should be done. At the end, and as a reminder, they write a brief description about it. Although I like User Story format as an Agilest, but I think the shared understanding concept is much more important than the written words of requirements.

Writing a documentation that is brief is an objective in itself. We rely on short term memory to preserve a lot of knowledge. Some of this knowledge, we may be not aware of its existence.

So, replacing Use Cases or other requirements documentation format with User Story format does not mean you implemented the approach of User Stories approach. You have to think of it per the original intent of the approach. One of the models that is helping us understand is the 3C model of Ron Jeffries.This model describes User story as Card, Conversion, and Confirmation.

By Card, it means a simple and small index card is sufficient to denote the User Story. One of the negative features of most requirements management software tools is that you can write any amount of content per User Story. By ensuring the limits of physical card constraints, we make sure of the small amount of contents that will be written. Reaching the physical limits is a good indication of either you are writing a lot of un-necessary details or the story is so big and worth breaking it into two stories.

The second word is Conversation: User story is not written by some person and handed off to the team for implementation. It it actually emerge from conversation between users, developers and testers. It represent a shared understanding rather than a complete and contractual specifications.

The third word is Confirmation: It the assurance of that, all conditions, and scenarios expected from users and testers are covered. It ensure we are not only thinking of happy scenarios, but also all scenarios and special cases.

There is no typical importance order for the 3Cs. Rather, they are complimentary to assure User Story is not a requirements documentation format, but a methodology of working with user needs that is aligned with Agile mindset.

User Story usually written in the format like this: 

Usually, the format may attract people of comprehensive documentation mindset to compare it with other formats. But the format is actually the least important part of User Story. 

From ahm507.blogspot.com