Device to communicate product requirements to the developers
A user story briefly describes how a software is used so that features can be identified. It is a device to articulate how each feature provides value to the user and serves as a conversation starter between users and developers.
The Product Backlog Items (PBIs) are usually expressed as User Stories. PBIs can also be expressed as use cases, that is how Marketing people usually talks about the applications of the product under development.
User stories should ideally be INVEST:
Independent Ideally stories can be implemented in any order, to allow maximum freedom to organise work in a sprint
Negotiable Story details can be negotiated between customers and developers
Valuable Stories must generate value to the customer
Estimable Stories should be simple enough to be estimated with a high degree of certainty
Sized correctly Smaller stories are easier to understand, estimate and implement. It must be big enough to generate value but no bigger than that. Another good reason to have small stories is that they should have just enough detail to start a conversation between customer and developer. The alternative is a long and detailed specification that will soon get old
Testable Stories should be written to make it easy to check. Writing tests early is a good practice so the limit cases are tackled upfront
A user story map provides a framework to create user stories along a timeline. Adopting the perspective of the customer, consider all the decisions and actions in time and use this train of though to generate the user stories in their context of usage.
