User story
A user story is a short description of a change to a product from the point of view of the person who wants it, usually written as 'As a [user], I want [capability], so that [benefit]'. It is a placeholder for a conversation, and the acceptance criteria attached to it say when the story counts as done.
The longer version
Ron Jeffries described a story as three parts, the three Cs. The Card holds a few words, the Conversation fills in the detail, and the Confirmation is the set of tests or acceptance criteria that show the story works. The card is thin on purpose. Detail written up front is out of date by the time the story reaches the top of the backlog, so the team talks it through when it is about to be built.
A story for a reporting tool might read 'As a project manager, I want to export a ticket list as CSV, so that I can share it with a client who has no login.' The role says who benefits, the capability says what changes, and the benefit gives the team a reason to weigh against the cost. The last clause is the one most often dropped, and it is the one that lets a developer propose a cheaper way to reach the same goal. A task such as adding a column to a table has no such reader, since nobody outside the team would recognise it as value.
A story is sized to fit inside one sprint, and a request too large for that is an epic to be split into several stories. Teams check a draft against the INVEST mnemonic, estimate it in story points, and often hold it back from sprint planning until it meets their definition of ready.
Common questions
What is the format of a user story?
The common template is 'As a [type of user], I want [a capability], so that [a benefit]'. The template is a convention a team can drop, and a story that names a real user, a change and a reason in plain words does the same job.
What is the difference between a user story and a requirement?
A requirement states what the system must do, often in formal and exhaustive terms. A user story is a lighter placeholder written from the user's side, with the detail agreed in conversation and recorded in acceptance criteria.
What is the difference between a user story and acceptance criteria?
A user story says who wants a change and why. Acceptance criteria are the checkable conditions attached to that story that say when it is finished, and a story is usually not ready to build until someone has written them.
Who writes user stories?
The product owner usually drafts them, though anyone who understands the user can, and the whole team refines them. Sprint planning is a poor place to meet a story for the first time, because the questions it raises are cheaper to answer earlier.
How small should a user story be?
A user story should be small enough to finish within one sprint and small enough for the team to estimate with some confidence. A story that cannot meet either test is usually an epic and gets split before it is taken in.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.