User Story Template: The Format, and a Card You Can Copy

A user story template has three lines and a checklist: “As a <who>, I want <what>, so that <why>”, followed by the acceptance criteria that say when it is done. The first line names a real person or role, the second names something they can do or see, and the third names the reason, which is the part that tells the team whether they solved the right problem. Everything below is about filling those lines well, plus a card you can copy.

This page is the format. For twenty filled-in stories across different products, see user story examples; for the criteria themselves, see acceptance criteria examples.

The format, and where it comes from

The three-part sentence is often called the Connextra format. The Agile Alliance glossary records that the role-feature-reason template↗ (opens in a new tab) was invented at Connextra in the UK in 2001, and that it is usually quoted as “As a… I want to… So that…”.

As a    <who: a specific user or role>
I want  <what: something they can do, see or get>
So that <why: the outcome it gives them>

The sentence was never meant to be the whole story. Ron Jeffries’ three Cs↗ (opens in a new tab), from the same year, describe a story as a card, a conversation and a confirmation: the card is a reminder, the detail comes from talking, and the confirmation is the check that the objective was met. Acceptance criteria are that confirmation written down.

Public-sector teams use the same shape. The GOV.UK Service Manual’s guide to writing user stories↗ (opens in a new tab) gives it as “As a… I need/want/expect to… So that…”, calls the goal the most important part, and suggests acceptance criteria written as “it’s done when…”. It also says every member of the team writes stories, not only the product manager.

Filling in each line

• As a: name the person who gets the benefit, as specifically as the team would recognise. “A returning customer” or “a site manager signing off a job” beats “a user”. If the only honest answer is “the developer”, it is probably not a user story; see the last section.
• I want: describe something the person can do or observe, not how it is built. “Pay with a saved card” is a want; “a card vault table” is an implementation.
• So that: name the outcome, not a restatement of the want. “So that I can pay with a saved card” adds nothing; “so that I can reorder in under a minute from my phone” tells the team what good enough looks like.
• Acceptance criteria: three to seven statements, each true or false, that a stranger could check. The main case, the edge cases you care about, and what must not change.

INVEST in six lines

Bill Wake’s INVEST checklist↗ (opens in a new tab), from 2003, is the usual test of whether a story is ready to work on. The Agile Alliance glossary gives the letters as:

• Independent: it can be built and shipped without waiting for another story.
• Negotiable: it captures the need, not a fixed contract; details are worked out together.
• Valuable: it delivers something a user or customer would notice, which usually means a thin slice through every layer rather than one layer done completely.
• Estimable: the team can say roughly how big it is. If nobody can, a question is missing.
• Small: it fits comfortably in one iteration, or for a kanban team, a few days of work.
• Testable: you could write down how to check it, even before a test exists.

The two that fail most often are Small and Testable. A story that fails Small gets split, and AI agent task decomposition covers splitting by outcome rather than by layer. A story that fails Testable has no acceptance criteria yet.

A template you can copy

Paste this into the description of a card on whatever board you use. The fields below the story are optional, but the first four lines are not.

Title:    <short outcome, e.g. "Reorder from order history">

As a      <specific user or role>
I want    <something they can do, see or get>
So that   <the outcome it gives them>

Acceptance criteria (it's done when):
  - <main case, true or false>
  - <an edge case you care about>
  - <what must not change>

Notes:    <who asked, links, screens, what was already tried>
Out of scope: <what this story deliberately does not cover>
Open questions: <anything that needs a decision first>

The “Out of scope” line saves more arguments than any other. A story for reordering from order history does not have to cover reordering from an email link, and saying so stops the conversation drifting.

When an AI assistant will do the work

A person who reads a story and is unsure walks over and asks. An AI assistant usually does not; it picks the most likely meaning and works until it believes it has finished. So a story an assistant will pick up needs the conversation written down, because there will not be one. Keep the story sentence, since the why still steers its choices, and add what a colleague would have learnt by asking:

As a      returning customer on mobile
I want    to reorder a past order in one tap
So that   I can repeat my weekly shop in under a minute

Where:        app/orders/[id]/page.tsx; cart API POST /cart/items
Constraints:  No schema changes. No new packages.
Acceptance criteria:
  - "Reorder" on a past order adds every item still on sale to the cart
  - Items no longer sold are listed in a message, not silently dropped
  - Quantities match the original order
  - Existing cart tests pass unchanged
Check:        Paste the test names and pass count.
              Needs a person: the button on a real phone.
If blocked:   Comment what you found and hand the task back.

Where, constraints, the check and what to do when blocked are the additions. Each one is explained, with rewrites, in how to write a task for an AI agent; this template only shows where they sit next to a story. If you would rather have the assistant draft the story from a customer email and approve it yourself, turning feature requests into tasks walks through that.

When a user story is the wrong shape

The format is a tool for describing value to a user. Some work has no user in that sense, and forcing it into the sentence produces something like “As a developer, I want to upgrade the database driver, so that the database driver is upgraded.” That helps nobody. The Scrum Guide itself does not require stories; it speaks only of Product Backlog items↗ (opens in a new tab), which can take any shape that makes the work clear.

• Bugs. The useful parts of a bug are steps to reproduce, what you expected, what happened and where. Write that. “As a customer, I want the export not to drop rows” hides the steps inside a sentence. An issue tracker for AI agents lists what a report needs before anyone can act on it.
• Chores and maintenance. Upgrades, renewals, clean-ups. A plain title and a reason are enough: “Upgrade the payment library before the old version stops being supported on 1 March.”
• Spikes and research. The outcome is an answer, so make the report the deliverable: “A comment comparing the two options, with a recommendation.”
• Small enhancements where the why is obvious. “Add a keyboard shortcut for search” does not improve by being dressed up.

A simple rule: use the story format when the why is not obvious and the who matters. Otherwise write a clear title and acceptance criteria. Sorting work into features, enhancements and bugs is a good first filter: most stories are features or enhancements, and bugs rarely want to be stories.

The same card on a fenbs board

On fenbs a story is a task of kind feature or enhancement. The story sentence and the acceptance criteria go in the Problem box, which over MCP is note and is written once. How the work will be done goes in the Plan box, plan, which is rewritten as people learn. When the work is checked, the Testing field records the result, from Not tested through Tested, Partly tested and Failed to Needs owner check, with notes on what was checked and what was not. Priority runs 1 to 10, with 1 the most urgent, and a task can carry a rough size from XS to XL, where XL means split it.

An AI assistant connected over MCP can draft stories with fenbs_create_item, fill in the plan, and record its checks with testStatus and testNotes. A person reads the evidence and moves the task to Completed. What fenbs does not have: sprints, story points, epics or due dates. The four lanes, To Do, Next Up, In Progress and Completed, carry the flow instead.