User Story
A user story is a short feature description from the user's perspective using the "As a [user], I want [goal], so that [benefit]" template. It is used in agile planning to keep features grounded in customer value rather than implementation detail, and is typically accompanied by acceptance criteria that define what "done" means for the story. The format was popularized by Kent Beck and the Extreme Programming community in the late 1990s and became the dominant unit of work in Scrum and other agile frameworks.
The canonical structure has three slots: As a (the role or persona), I want (the goal or capability), so that (the benefit or business value). Example: "As a logged-in customer, I want to save items to a wishlist, so that I can buy them later without having to find them again." The Bill Wake INVEST criteria (2003) define what makes a good user story: Independent (can be built without depending on another story), Negotiable (the details can shift as we learn), Valuable (delivers customer or business value), Estimable (the team can size it), Small (fits in a sprint, typically 1 to 3 days of work), Testable (acceptance criteria can be evaluated). User stories are explicitly distinguished from technical tasks (which describe how the team will implement something) and from epics (large items that get broken down into multiple user stories). The 2024 to 2026 evolution: many modern teams have moved away from rigid user story format to outcome-based or job-story format ("When [situation], I want to [motivation], so I can [outcome]" from Alan Klement's JTBD work), which captures the trigger context that the classical format misses.
Ryan's Take
User stories were useful for shifting teams from "spec-driven" to "customer-driven" thinking in 2003. Today they're often a ceremony: someone writes "As a user I want to do thing" at the top of a Jira ticket, the engineer ignores it and reads the technical description below, and the story format adds zero value. The format works when it forces the team to articulate the user and the benefit. It fails when it becomes a fill-in- the-blank ritual. If your user stories all start with "As a user" without specifying which user, you've stopped doing user stories and started doing mad-libs.
What founders get wrong: Confusing the user story format with actual customer-centricity. A team that writes user stories all day can still be deeply customer-disconnected if those stories are invented at a whiteboard rather than pulled from real customer research. The format is a prompt; the customer evidence is the work.
Related: Product Backlog · Agile · Scrum · Product Management · Jobs To Be Done
FAQ
What is a user story?
A short description of a feature from the user's perspective using the "As a [user], I want [goal], so that [benefit]" format. Used in agile planning to keep features grounded in customer value, and typically accompanied by acceptance criteria that define what done means.
What are the INVEST criteria for user stories?
Bill Wake's 2003 framework: Independent (no dependency on other stories), Negotiable (details can shift), Valuable (delivers customer or business value), Estimable (team can size it), Small (fits in a sprint), Testable (acceptance criteria can be evaluated). A good story passes all six.
What is the difference between a user story and a job story?
User story format: "As a [user], I want [goal], so that [benefit]." Job story format (Alan Klement, JTBD): "When [situation], I want to [motivation], so I can [outcome]." Job stories add the situational trigger that user stories often miss, which is why many modern teams prefer them.
Find this article helpful?
This is just a small sample! Register to unlock our in-depth courses, hundreds of video courses, and a library of playbooks and articles to grow your startup fast. Let us Let us show you!
Submission confirms agreement to our Terms of Service and Privacy Policy.