How to Write a Good User Story

A user story that only states what to build, with no reason attached, gives an engineer a task list dressed up in a sentence template. The version that actually works states the reason too, because the reason is what lets the person building it make good calls on the parts the story does not spell out.

What is the actual user story template?

The standard format has three parts, and the order matters:

As a [specific type of user] I want [a goal, stated as an outcome, not a UI element] So that [the reason this matters, ideally tied to a benefit the user or the business gets]

Example: "As a returning customer who has already saved a payment method, I want to complete checkout without re-entering my card details, so that I do not abandon a repeat purchase over a friction point I have already solved once before."

Notice what that example does not do: it does not say "add a 'saved cards' dropdown to the checkout page." That implementation detail is left to design and engineering, who may find a better way to deliver "does not re-enter card details" than the one you imagined when you wrote the story.

How do you check whether a story is actually ready to build?

Run it through INVEST before it enters a sprint:

• Independent: Can this ship without waiting on another unstarted story? If not, either sequence them explicitly or combine them.
• Negotiable: Does the story leave room to discuss the best implementation, or does it dictate one? A story that reads like a spec has skipped a conversation that should happen.
• Valuable: Does the "so that" clause name a real benefit to a real user or the business? If you cannot state one, question whether this story belongs on the backlog at all.
• Estimable: Can the team give a rough size without needing to research it first? If not, it may need a short technical spike before it is a real story.
• Small: Can it realistically finish inside one sprint? A story spanning multiple sprints is usually several stories wearing one description.
• Testable: Is there a clear way to verify it is done? If you cannot write acceptance criteria for it, the story is not specific enough yet.

What do acceptance criteria actually look like?

Acceptance criteria are the specific, checkable conditions that turn "so that I do not abandon a repeat purchase" into something a QA pass or a code review can verify directly.

Continuing the example above:

• Given a returning customer with a saved payment method, when they reach checkout, they see their saved card pre-selected by default.
• Given a customer wants to use a different card, they can switch to a new card entry in no more than one additional click.
• Given a customer completes checkout with a saved card, the order confirms without requiring them to re-enter the CVV, consistent with the platform's existing payment security requirements.

Each criterion is a specific, testable condition, not a restatement of the story in slightly different words. If two acceptance criteria say roughly the same thing, one of them is not adding information and should be cut.

What do good user stories look like across different kinds of work?

A feature story: "As a project lead managing multiple team members, I want to see everyone's task status on one dashboard, so that I do not have to ask each person individually for a status update."

A technical enabler story (still framed around value, not just implementation): "As a user on a slow connection, I want the dashboard to load in under two seconds, so that I do not abandon the page before it finishes rendering."

A bug-fix framed as a story: "As a user who saved a draft and lost connectivity, I want my draft preserved when I reconnect, so that I do not lose work I have already put time into."

All three keep the same shape: a specific user, a goal stated as an outcome, and a reason that explains why it matters, even when the underlying work is more technical than user-facing.

What mistakes turn a story into a disguised task list?

The most common mistake is writing the "I want" clause as a UI instruction instead of a goal: "I want a blue 'Save' button in the top right" is a design decision wearing a story's clothing, and it removes the team's ability to propose a better interaction. State the goal ("I want my changes saved without losing my place on the page") and let the interface be a design and engineering decision downstream of that.

A second common mistake is stacking multiple goals into one story with an "and": "As a user, I want to filter and sort and export my results, so that I can find what I need." That is at least two, probably three, separate stories, each independently valuable and independently testable, and combining them makes the story impossible to size accurately or ship incrementally.

Who this is for, and who it is not for

This template fits a product manager, product owner, or delivery lead writing backlog items for a team that works in an iterative, story-based process, the exact territory covered in Builders Camp's Beyond Agile bootcamp, which focuses on outcome-driven planning and a healthy backlog over ceremony for its own sake. It is not the right format for a strategic initiative spanning multiple quarters; that belongs on a product roadmap or in a PRD first, broken down into individual stories only once the direction is scoped.

If the story you are trying to write keeps feeling vague, the underlying problem is often that discovery has not actually happened yet; a discovery interview script run first usually produces a sharper "so that" clause than guessing at one during backlog grooming.

What to do with this template right now

Write the "so that" clause first, before the "I want" clause, and if you cannot state a real reason, do not write the story yet. Then run it through INVEST, split anything that fails Independent or Small, and attach acceptance criteria specific enough that two different engineers would agree on what "done" means without asking you.

Builders Camp's Beyond Agile bootcamp runs 1 week across 2 live sessions, taught by Andre Albuquerque, and works through exactly this kind of backlog discipline as part of a broader operating model for teams tired of Agile rituals that no longer produce outcomes.