How to write user stories: format, examples and the INVEST checklist

What a user story is, and what it is for

A user story describes something a person wants to achieve, written from that person's point of view. It is deliberately short. The idea is that the story is not the requirement itself; it is a reminder to have a conversation, followed by agreement on how to check that the need has been met.

Agile teams use stories because they keep attention on the person and the value, rather than on technical features. They are small enough to plan in a sprint, easy to reorder in the backlog and clear enough that a business user can read them. For a business analyst, writing and refining stories is a core daily task, as described in what a business analyst does.

The three parts: card, conversation, confirmation

• Card: the short written statement.
• Conversation: the discussion between the analyst, product owner, developers and testers that fills in the detail.
• Confirmation: the acceptance criteria that say how to check the story is done.

A story with only the card is a wish. A story with a card, a conversation and confirmation is ready to build.

The standard format

The most common template is:

As a [type of user], I want [goal], so that [benefit].

Each part does a job.

• As a [type of user] names who benefits. Use a real role such as "returning customer" or "claims handler", not "the system" or "user" if you can be more specific.
• I want [goal] says what they want to do, as an outcome, not a screen or a technology.
• So that [benefit] gives the reason. This is the most valuable clause and the one most often left out. It lets the team judge priority and suggest alternatives.

The template is a thinking aid, not a law. Some teams prefer alternatives such as job stories ("When I... I want to... so I can..."). What matters is that the need, the person and the reason are all clear.

A quick example

"As a library member, I want to renew a borrowed book online, so that I do not have to visit the library just to extend the loan."

Notice what is missing: no button names, no database fields and no technology. Those are decisions for later, and leaving them out gives the team room to propose the best solution.

Check every story with INVEST

The INVEST criteria are a quick checklist for story quality. Use them in refinement sessions, before a story enters a sprint.

A story that fails two or three checks is usually too big or too vague. The fix is almost always to clarify it, split it, or both.

A step-by-step method for writing a story

1. Start from a problem. Write a one-sentence problem statement first. If you cannot, you are not ready to write stories.
2. Name the user precisely. Different users have different needs. A "member" and a "librarian" would want different things from a renewal feature.
3. State the goal as an outcome. Ask "what does the user want to accomplish?" not "what screen do we need?".
4. Add the benefit. Finish "so that..." honestly. If you cannot think of a benefit, question whether the story is needed.
5. Add acceptance criteria. Write three to six checks covering the normal case, a failure case and a boundary. See acceptance criteria and Gherkin examples.
6. Note what is out of scope. A single line prevents later arguments.
7. Review with the team. A developer will find technical gaps and a tester will find untestable wording.
8. Link it. Put it under the right epic in the tracker, with a link to any process model or documentation. See Jira for business analysts.

A worked example: renewing a library book

Willow Library is a fictional town library with a small web app. The head librarian, Tomas, says, "Members should be able to manage their loans online." This is far too broad for a story. Here is how an analyst, Aisha, works on it.

Step 1: ask about the problem

Aisha asks what is going wrong now. Tomas explains that many members visit only to renew books, which creates queues at the desk. A quick count by the desk staff over a week supports this. Aisha writes: "Members must visit the desk to renew books, which creates queues and wastes the members' time."

Step 2: split the broad idea

"Manage loans online" could include viewing loans, renewing, reserving and paying fines. Aisha lists these and splits them into separate stories. She chooses the first one for the next sprint:

As a library member, I want to renew a borrowed book online, so that I do not have to visit the library just to extend the loan.

Step 3: add acceptance criteria

• A signed-in member sees a Renew button next to each book they have on loan.
• Renewing extends the due date by the standard loan period, shown before and after.
• A book that another member has reserved cannot be renewed, and the member sees a clear message.
• A book can be renewed only a limited number of times set by library policy, after which the message says so.
• An overdue book cannot be renewed online and the member is asked to visit the desk.

Step 4: check against INVEST

It is independent of reservations (the reserved-book rule uses existing data), valuable (the "so that" is clear), small (one action), estimable and testable. The only negotiable decision is how to show the message. Aisha also records one out-of-scope line: paying fines online is a separate story.

Step 5: the conversation

In refinement, the developer asks what counts as "standard loan period" for audio books. Tomas says audio books have a shorter loan. Aisha adds the rule to the acceptance criteria. The tester points out the case of a book that is due today. Aisha adds a criterion for that. Notice that the conversation improved the story more than the first draft did.

How to split a story that is too big

Large stories hide risk. If a story would take more than a sprint, or the team cannot agree on an estimate, split it. These patterns work well.

• By workflow step. "Apply for a loan" becomes "start an application", "upload documents", "submit and receive confirmation".
• By rule or variation. Start with the standard case, then add special cases such as joint applicants.
• By data or user type. Support one product or one user group first.
• By operation. Create, view, change, delete often split cleanly.
• By quality level. A basic version first, then performance or polish later.
• By spike. If the uncertainty is technical, a short investigation story can precede the real one.

Always split vertically, so each piece still delivers something a user can notice, rather than horizontally into "build the database" and "build the screen". A story that delivers value on its own can be released and tested alone. The same ideas help when you prioritise: see MoSCoW prioritisation.

Common mistakes, with before and after

Another common mistake is writing acceptance criteria that repeat the story or describe implementation. Criteria should describe observable behaviour. Another is treating the story as a contract that must never change; it is meant to be discussed and refined. Finally, do not lose the "so that". Without it the team cannot tell whether a cheaper way would satisfy the same need.

Where stories fit, and what to practise next

Stories sit between higher-level goals and detailed tasks. A business goal leads to an epic, an epic breaks into stories, and stories break into tasks that developers carry out. Documents such as the BRD can feed stories, and stories can be traced to tests; see the traceability matrix guide. Who decides priority and accepts completed work? In Scrum, the product owner, which the article on the agile BA and product owner explains.

To practise, take a process from your own life or work, write the problem statement, then draft three stories with acceptance criteria. Ask someone to read them cold and point to any word that could mean two things. Our free requirements example works through a similar exercise on a fictional cancellation rule. The BA Lab includes story-writing tasks with automatic checks for vague words and missing criteria, and there is a short entry for every term in the glossary.

Frequently asked questions