Requirement from the user perspective: 'As a [role] I want [feature] so that [benefit]'.
A User Story describes a requirement from the user’s perspective in the format: As a [role] I want [feature] so that [benefit]. This format forces every requirement to be tied to a concrete benefit rather than merely listing technical tasks. User Stories are the most common format for Product Backlog items and make requirements understandable for everyone involved.
A good example: As a customer I want to filter products by price so that I can find suitable items faster. The story names the role, the desired function, and the reason. During Refinement, the team checks the story against the INVEST criteria: Is it independent of other stories, negotiable in detail, valuable to the user, estimable in effort, small enough for a Sprint, and testable? If a story is too large, it gets split into smaller stories that each deliver independent value.
User Stories go back to Kent Beck and Extreme Programming. The INVEST acronym was coined by Bill Wake. An important point is that the story itself is merely a conversation starter. The actual clarification happens in the discussion between the Product Owner and the team.
Apply methods, don't just know them. View trainings and workshops
