You came for a user story template — the As-a / I-want / So-that format, the INVEST checklist, the acceptance-criteria block. It's below; copy it into Jira, a doc, or wherever stories live. But know the failure mode: a story captures a need in one sentence and then floats free of the product decision that justified it. When that decision changes, the story keeps sitting in the sprint, quietly building the wrong thing. Draftlize gives you the same format — and links each story to the decision it rests on.
A user story is one sentence in three parts, plus the criteria that make it testable. This is the whole template — it's the same shape agile teams have used forever.
The specific user or persona, not "the user." "As a PM reviewing a roadmap" frames the need; "as a user" frames nothing. The role is what keeps the story honest about who it serves.
The thing they want to do, stated as a capability, not a UI. "I want to cite a decision from a spec" — not "I want a dropdown." How it looks is a design decision; the story is about the goal.
The outcome that makes it worth doing. This is the part teams drop and the most important one — it's the test of whether the story is worth building at all, and the first thing to check when scope is questioned.
The conditions that make it shippable, ideally as Given/When/Then. This is where a story becomes testable. See the dedicated acceptance criteria guide for the full pattern.
A good story is Independent, Negotiable, Valuable, Estimable, Small, Testable. Run a draft story against these six and the weak ones (too big, not testable, no value) fall out before they reach a sprint.
Worked example: As a PM reviewing a roadmap, I want to cite a decision from a spec, so that I don't re-explain it every sprint.
The benefit clause references a product decision — "so that" some goal is served. But in a ticket it's just text, a restatement of a decision that lives somewhere else. The story and the decision it depends on are two disconnected things that happen to agree, for now.
The goal behind the story shifts — you re-scope, you reprioritize, you drop a segment. The story is still sitting in the backlog with its original "so that," now pointing at a reason that no longer holds. Nobody re-reads every story when a decision moves, so the sprint quietly builds to a stale why.
The criteria were written against a spec that has since changed. The story says "done when X," the spec now says Y, and the gap surfaces in review or QA — late, expensive, and avoidable if the criteria had been linked to the spec instead of copied from it.
In Draftlize a story isn't a standalone ticket — it's a card whose "so that" links to the actual decision card it serves. The benefit isn't restated; it's referenced. Open the story and you can walk straight to the decision that justifies it.
Because the link is real, changing the decision behind a story turns the story stale automatically — the way a build system invalidates everything downstream of a changed file. You see which stories just lost their reason, before a sprint builds them anyway.
When Claude Code or Cursor picks up a story over MCP, it reads the linked decision and acceptance criteria too — so it implements against the current intent, not a sentence that lost its meaning three decisions ago.
A user story captures a need in a sentence. It can't tell you when the decision that made the need real has moved on.Keep the format. Let the "so that" link to the decision, not just describe it.
The classic template is "As a [role], I want [capability], so that [benefit]." The role names who it is for, the capability names the goal (not the UI), and the benefit names why it is worth doing. Acceptance criteria are added to make it testable.
A user story is a short, informal statement of a need from the user's perspective, meant to start a conversation. A use case is a more detailed description of the interaction steps between a user and the system. Stories are lightweight and agile; use cases are heavier and more complete.
A good story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. The most common failures are stories that are too big to estimate, have no clear value in the "so that," or are not testable because there are no acceptance criteria.
The story states the need; the acceptance criteria state the conditions under which it is considered done, usually as Given/When/Then. The story is the why and what at a glance; the criteria are the precise, testable definition of success.
Take the template above, or write each story as a card in Draftlize linked to the decision it serves — so when the decision moves, the story flags stale instead of quietly building the wrong thing.
Start free with $5