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.