User story template: the format, with examples

The most common format, first used by a team at the British company Connextra around 2001:

As a <type of user>, I want <something>, so that <a reason or benefit>.

• As a names who it's for. Be specific: "a returning customer" says more than "a user".
• I want says what they want to do, not how the screen should look.
• So that says why. It's the part most often skipped, and the part that lets the team find a better way to deliver it.

A product

• As a returning customer, I want to reorder a past purchase in one step, so that I don't have to find each item again.
• As a new user, I want to sign in with my Google account, so that I don't have to make up another password.
• As an account owner, I want to see which teammates haven't logged in this month, so that I can stop paying for seats nobody uses.

An internal tool

• As a support agent, I want to see a customer's last 5 orders next to their ticket, so that I can answer without switching screens.
• As a finance manager, I want invoices over 5,000 flagged for approval, so that large payments get a second check.

Content and marketing

• As a visitor comparing tools, I want to see the pricing for teams on one page, so that I can decide without contacting sales.
• As a subscriber, I want to choose how often I get emails, so that I don't unsubscribe from all of them.

Ron Jeffries, one of the creators of extreme programming, described a story as 3 Cs:

• Card: the short written story. Small enough to fit on an index card.
• Conversation: the discussion between the people who want it and the people who'll build it, where the details are worked out.
• Confirmation: the acceptance criteria that say when the story is done.

The card alone is never enough. If a story arrives with no conversation, expect it to be built differently from what was meant.

Bill Wake's INVEST checklist tests whether a story is ready to work on:

• Independent: it can be built without waiting for another story.
• Negotiable: the details can still change in conversation.
• Valuable: someone outside the team would notice and care when it's done.
• Estimable: the team understands it well enough to size it.
• Small: it fits comfortably in a sprint, ideally in a few days.
• Testable: you can tell when it's done.

A story too big for a sprint is often called an epic. Split it so each part still delivers something a user notices:

• By steps in a workflow: "search", then "filter results", then "save a search".
• By type of user: the version for new users first, power users later.
• By rule or case: the common case first, the exceptions next.
• By data: one payment method now, the rest later.
• Simple first, then better: a plain version that works, then the polish.

Avoid splitting by technical layer, like "the database part" and "the screen part". Neither half is usable on its own.

• The system as the user: "As the system, I want to store the date". That's a task, not a story. Write it as a task or a checklist item.
• No reason: leaving out "so that" removes the one part that helps the team find a better answer.
• A solution in disguise: "I want a dropdown" decides the design. "I want to choose my country quickly" leaves room.
• Everything as a story: bugs, chores and spikes don't need the format. Use it where the user's view matters.

One story per card works well. In craaft:

• Put the story sentence in the card title or the first line of the description.
• Add the acceptance criteria as a checklist on the card, so progress shows on the card itself.
• Give each card a size, and split any card that's too big to finish in a few days.
• Keep the conversation in the card's comments, with @mentions, so the decisions stay with the story.
• Start from the sprint planning template if you work in sprints.