User stories are nice informal way to share requirements for software development. While I was working at IFMC(now Telligen) many years ago we went through a process to get to CMMI Level 1. In the process we started gathering these extensive requirement documents. I felt bad for the business analyst who put them together as no one read them. User stories are neither lengthy or vague like some requirements documents.
User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. – Mike Cohn Moutain Goat Software
User stories are short and right to the point. It is simply trying to gather the most important information, or as Joe Friday would say in Dragnet, “just the facts ma’m.” We simply want to capture the “who”, “what” and the “why” of the requested feature or enhancement. The best way to capture a user stories is simply to write it down on a note card or stick note and add this to your product backlog.
The form of a user story usually fits the basic template. This basics template is As a <role>, I want <feature/enhancement> so that <benefit>. For example, “As a driver, I want a radio so that I can be entertained while driving”. User stories should also include some acceptance criteria, or definitions or indications of what “done” is.
The user story won’t always be complete. It may need some additional refinement, it is created to start the conversation between the business and development. Anyone can create a user story, developers, testers, and product owners. The product owner should review all user stories to make sure they have the proper information.