As its name suggests, a user story describes how a user or customer uses the product–a digital product is captured from the perspective of the users. This avoids a solution-centric view where we worry more about how to provide and implement the product features than why and how people will use them.
First and foremost thing we need to get rid of Design phase is “ASSUMPTIONS” . It is very important for team to have frequent conversations with the End/Business Users to remove the danger stuff call assumption.
Maybe it’s helpful to take a quick look at the context in which user stories emerged. Stories were first used in Extreme Programming in combination with the role of an onsite customer. The onsite customer is a member of the user community who is collocated with the development team. The individual would discuss with the team what should be built in the next iteration, and captured the conversation as stories to remind everyone of what was discussed.
User stories are a very simple tool—we simply tell stories about how users are likely to interact with the product and capture their essence. That’s it. User stories are great at capturing product functionality, things people can do with a digital product like searching, evaluating, and purchasing products online. You can also use stories to capture non functional aspects of a product, such as performance, robustness, and interoperability.
Its always recommended to create a User stories in human readable format. This makes the Dev team and Client are on the same page.