User Story in Agile

User stories are used with Agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.)

1. A user story represents a value adding requirement of the product.
2. Contract between development team and PO that discussion will take place before implementation.
3. This usually follows the following template:"As a <user type> I want to <do some action> so that <desired value added result>“.
4. INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable.
5. Implemented by a development team in one sprint.
6. User stories are Complemented by with conditions of satisfaction.

User stories Vs Use Cases

User stories

1. Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.
2. Must be accompanied by Acceptance Testing procedures (acceptance criteria) for clarification of behaviour where stories appear ambiguous

Use Cases

1. Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
2. May be delivered in a stand-alone document.