User story
YOO-zer STOR-ee
A short, plain-language description of a feature from the perspective of the user who wants it.
A user story describes a feature from the user's perspective. The classic format: 'As a [type of user], I want [action] so that [benefit].' For example: 'As a DevOps engineer, I want to receive Slack alerts when a deployment fails so that I can respond immediately.'
User stories work because they keep the focus on the user's need rather than the implementation. They are deliberately incomplete. A user story is a placeholder for a conversation between the PM, designer, and engineer about what the user actually needs.
Good user stories have acceptance criteria: specific conditions that must be true for the story to be considered complete. Epics group related user stories together. 'Slack alert is sent within 30 seconds of deployment failure.' 'Alert includes the service name, environment, and error message.' These criteria define 'done.'
Examples
A PM writes user stories for a sprint.
Story 1: 'As an admin, I want to set alert thresholds per service so that I only get notified about significant issues.' Acceptance criteria: threshold is configurable per service, default is 5 errors in 5 minutes, changes take effect immediately.
A user story is too large and gets broken down.
The original story: 'As a user, I want a dashboard to monitor all my services.' This is too big. The PM breaks it into: 'view a list of services and their status,' 'see error rate trends for each service,' and 'filter services by environment.'
A designer uses user stories to inform wireframes.
The story says the user wants to 'quickly see which services are healthy and which are not.' The designer creates a dashboard with green/red status indicators and sorts unhealthy services to the top.
In practice
Read more on the blog
Frequently asked questions
How detailed should a user story be?
Enough to start a conversation, not enough to be a specification. The story captures the who, what, and why. The details emerge through conversation between the PM, designer, and engineer. Acceptance criteria add specificity without over-prescribing the solution.
What is the difference between a user story and a task?
A user story describes value from the user's perspective. A task describes work from the team's perspective. A single user story might generate multiple tasks: design the UI, build the API endpoint, write tests, update documentation.
Related terms
A large body of work that can be broken into smaller user stories, representing a significant feature or initiative.
A meeting where the team selects which work to complete in the upcoming sprint and plans how to accomplish it.
A document that defines what a product or feature should do, who it serves, and how success will be measured.
A software development methodology that delivers work in short iterations with continuous feedback and adaptation.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.