How to Write User Stories: Template and Examples

This guide takes you from a vague feature request to user stories a team can estimate, build and accept in a sprint. You’ll get a card template, an acceptance criteria format, an INVEST checklist, and five worked examples from one product. If you want the ideas behind them first (why the card matters less than the conversation, and what the 3 C’s are), read User stories in Agile. This page is the practical part.

One product runs through every step: an online booking app for a chain of veterinary clinics. Pet owners book appointments, clinic receptionists manage the diary, and vets see their day’s list. The clinic manager’s request is one line: “We need online booking.”

Who this is for

• New product owners and business analysts writing their first backlog.
• Developers and testers who are handed stories that can’t be built or tested as written.
• Experienced teams whose stories have drifted into mini-specifications nobody reads.

Before you start

• Know who the users are. Not “the user”: the actual roles. In the scenario that’s pet owners, receptionists and vets.
• Have someone who can answer questions. A product owner or business expert who’ll be in the conversation, not just write the card.
• Agree what done means. Your team’s Definition of Done covers quality for every story; acceptance criteria only cover what’s specific to this one.

Step 1: Start from a user and a goal, not a feature

“Online booking” is a feature. Stories start from someone trying to get something done. For each user role, write down the goals they have that the product should help with, in their language.

In the scenario: a pet owner wants to get their dog seen this week without phoning during work hours. A receptionist wants fewer no-shows. A vet wants to know why each animal is coming in before the appointment starts.

Step 2: Lay out the journey before you write cards

List the steps a user goes through, left to right, then the stories under each step. This is a lightweight story map, and it shows gaps that a flat list of stories hides.

In the scenario: the pet owner journey is: find a slot, choose a vet, give the reason, confirm, get reminded, cancel or rebook. Laying it out shows nobody had thought about cancelling, even though cancellations are what make no-shows go down.

Step 3: Write the card as a prompt for a conversation

Use the standard template, but treat it as a reminder of who and why, not a specification:

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

The “so that” is the part people skip and the part that matters most. It tells the team what problem they’re solving, which lets them suggest a better solution than the one on the card.

In the scenario: “As a pet owner, I want to book an appointment online so that I don’t have to phone the clinic during work hours.” The “so that” tells the team that the evening and weekend experience matters most.

Step 4: Have the conversation

The card is the start. Get the product owner, a developer and a tester together for ten to twenty minutes per story. Ask: what does the user see first? What can go wrong? What’s the smallest version that still helps? What’s out of scope?

Write the answers down as acceptance criteria and notes. Don’t turn them into a specification document.

In the scenario: the conversation reveals that new clients can’t book online because the clinic needs their pet’s history first. That becomes a separate story, and the first story is limited to registered clients.

Step 5: Write acceptance criteria as Given / When / Then

Acceptance criteria are how everyone knows the story is finished. Write each one as a short example:

• Given some starting situation,
• When the user does something,
• Then this is the result.

Three to six criteria per story is normal. More than eight usually means the story is too big. Cover the main path and the failure cases that matter; leave general quality (performance, accessibility, security) to the Definition of Done.

In the scenario: one criterion reads: “Given I’m a registered client, when I choose a slot that was booked a moment ago by someone else, then I’m told it’s no longer available and shown the next three free slots.” That came straight out of the conversation in Step 4.

Step 6: Check every story against INVEST

Before a story goes into sprint planning, check it against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. Use the checklist in the templates. A story that fails Small or Estimable isn’t ready; send it back to refinement.

In the scenario: “As a vet, I want to see my day’s appointments” passes everything. “As a clinic manager, I want reports” fails Estimable and Small: which reports, for what decision? It goes back for a conversation with the manager.

Step 7: Split stories that are too big

A story should fit comfortably in one sprint, ideally a few days of work. Split by value to the user, not by technical layer. Useful ways to split:

• Steps in the workflow: book now, rebook later.
• Business rules: registered clients first, new clients later.
• Variations: one clinic first, then all clinics.
• Happy path first: the main path in one story, the less common cases in the next.

Never split into “front end” and “back end” stories. Neither is valuable on its own and neither can be accepted by a user.

In the scenario: “As a pet owner, I want to manage my appointments” splits into three stories: cancel an appointment, rebook to another slot, and get a reminder the day before.

Step 8: Get the story ready for the sprint

A story is ready when the team understands it well enough to estimate it, the acceptance criteria are written, and anything it depends on is either done or in the same sprint. Don’t create a heavy entry checklist; the conversation and INVEST check are usually enough.

In the scenario: the booking stories for registered clients are ready for sprint 1. The new-client story waits until the clinic decides how pet history will be captured.

Copy-paste templates

Story card

Title: <short verb phrase, e.g. "Book an appointment online">

As a <type of user>
I want <goal>
so that <reason / outcome>

Notes from the conversation:
- <decision or assumption>
- <out of scope>

Acceptance criteria:
1. Given <context>, when <action>, then <result>
2. Given <context>, when <action>, then <result>
3. Given <context>, when <action>, then <result>

INVEST checklist

[ ] Independent   Can be built and released without waiting for another story
[ ] Negotiable    The details can still change in conversation; it isn't a contract
[ ] Valuable      A user or the business would notice if it shipped
[ ] Estimable     The team knows enough to size it
[ ] Small         Fits comfortably in one sprint (ideally a few days)
[ ] Testable      The acceptance criteria say how we'll know it works
Any box unticked -> not ready; back to refinement.

Five worked examples (veterinary booking app)

1. Book an appointment online
   As a pet owner, I want to book an appointment online
   so that I don't have to phone the clinic during work hours.
   - Given I'm a registered client, when I pick a free slot and confirm, then the slot is booked and I get a confirmation email.
   - Given I'm a registered client, when the slot I chose was just taken, then I'm told it's gone and shown the next three free slots.
   - Given I'm not logged in, when I try to book, then I'm asked to sign in first.

2. Give the reason for the visit
   As a pet owner, I want to say why my pet needs to be seen
   so that the vet can prepare before the appointment.
   - Given I'm booking, when I reach the reason step, then I can choose a common reason or type my own (up to 300 characters).
   - Given I chose "vaccination", when I confirm, then the booking is marked as a vaccination slot (15 minutes).
   - Given I've typed more than 300 characters, when I try to continue, then I'm told the limit and my text is kept so I can shorten it.

3. Get a reminder
   As a pet owner, I want a reminder the day before
   so that I don't forget the appointment.
   - Given I have an appointment tomorrow, when it's 6 pm today, then I receive a text and an email reminder.
   - Given I've opted out of texts, when the reminder is sent, then I receive the email only.
   - Given I book less than 24 hours before the appointment, when the booking is confirmed, then no separate reminder is sent.

4. Cancel an appointment
   As a pet owner, I want to cancel online
   so that the slot can go to someone else and I'm not charged a no-show fee.
   - Given my appointment is more than 24 hours away, when I cancel, then it's cancelled with no fee and the slot becomes free.
   - Given my appointment is less than 24 hours away, when I try to cancel, then I'm shown the late-cancellation policy before confirming.
   - Given I've cancelled, when I look at my appointments, then the cancelled one is shown as cancelled and I get a cancellation email.

5. See the day's list
   As a vet, I want to see my appointments for today with the reason for each
   so that I can prepare before each one starts.
   - Given I'm logged in at my clinic, when I open the day view, then I see my appointments in time order with pet name, owner and reason.
   - Given an appointment is cancelled, when I refresh the day view, then it no longer appears.
   - Given I'm not working today, when I open the day view, then I see "No appointments today" rather than an empty page.

Common mistakes

Technical stories. “As a developer, I want a database table for appointments.” No user wants that. Fix: write the user story it supports and keep the technical work as tasks inside it.

A missing or circular “so that”. “As a pet owner, I want to book online so that I can book online.” Fix: ask “why does that matter to them?” until you reach a real outcome.

Acceptance criteria as a UI spec. “The button is blue and 40px high.” Fix: criteria describe behaviour and outcomes; design details live in the design, and quality lives in the Definition of Done.

Stories too big to finish. A story that takes the whole sprint, or more. Fix: split by workflow step, business rule or variation (Step 7), never by technical layer.

Writing stories alone. The product owner writes perfect cards at their desk and hands them over. Fix: every story gets a conversation with the people who will build and test it.

Story inflation. Stakeholders add “just one more thing” during the sprint. Fix: new requirements become new stories, prioritised in the backlog.

You’re done when

• Each story names a real user role and a real outcome in its “so that”
• The team has had a conversation about every story going into the sprint
• Each story has three to six Given/When/Then acceptance criteria
• Every story passes the INVEST checklist
• Stories that were too big are split by user value, not by technical layer
• General quality is covered by the Definition of Done, not repeated in each story