Add Your Heading Text Here
User story
A user story is a short, plain-language description of a feature told from the point of view of the person who wants it, usually in the form 'as a [user], I want [goal], so that [benefit]'. It captures a need small enough to build in a single iteration, and it keeps the focus on the user rather than the implementation.
What it means
User stories exist to keep teams talking about outcomes instead of specs. The short format is deliberate. It is a placeholder for a conversation, not a full requirement on its own, which is why stories are usually paired with acceptance criteria that pin down what 'done' means. The story says who wants what and why. The criteria say how you will know it works.
In Azure DevOps, User Story is a work item type in the Agile process, sitting under Features and Epics in the backlog. Teams manage stories on boards, link them to tasks and tests, and trace them back to the higher-level goals they support. Written well, a story is small, independent, and valuable on its own, which is roughly what the INVEST checklist is getting at.
In practice
'As a returning shopper, I want to save my payment details, so that I can check out faster next time.' That single sentence tells the team who benefits, what they want, and why it matters, and it leaves the how open for the team to work out with the product owner.
FAQ
What is the difference between a user story and a use case?
What makes a good user story?
Manage requirements the modern way
Modern Requirements brings documentation, traceability, and reviews together inside Azure DevOps.
