A user story is a small, plain-language statement of something a user wants a system to do. Martin Fowler defines user stories simply as “chunks of desired behavior of a software system,” used as smaller units of functionality for planning and prioritization in agile development.
The Agile Alliance glossary frames the practice around the team and customer working together: “in consultation with the customer or product owner, the team divides up the work to be done into functional increments called ‘user stories.’” A story is meant to be a brief descriptive sentence, often written on an index card or sticky note, that serves as a reminder of value rather than a finished requirements document.
A widely used template, dating from around 2001, captures a story in a single sentence of the form “As a role, I want a goal so that some benefit.” The point of the format is to keep the user’s role and motivation in view, not to spell out every detail in advance.
User stories are deliberately not exhaustive specifications. They are placeholders for a conversation: the brief text on the card prompts the developers and the customer to talk through the details when the work is about to be done. This keeps requirements lightweight and responsive to change, which suits the short feedback cycles of agile methods such as Extreme Programming and Scrum.