A user story is a small piece of work described from the point of view of the person who benefits from it. This guide breaks down the "As a…, I want…, so that…" template, explains the INVEST checklist for good stories, and shows how to split a big idea into stories a team can finish. About 12 minutes to read.
A user story describes a need in everyday words, from the user's side of the screen. It deliberately leaves out how to build it. That is worked out together, by the people who will build it, in conversation with the people who need it.
A well-known way to remember this is Ron Jeffries' three Cs:
Do I have to use user stories? No. The Scrum Guide only asks for a Product Backlog of clear items. User stories are a popular way to write those items because they keep the focus on people and value. A bug fix or an upgrade can stay a plain task.
Most teams use one simple sentence. Each part has a different job, and a story is only as strong as its weakest part.
The person who gets the benefit. Be specific enough that you could go and talk to them.
What they want to be able to do, in their words, not the team's.
The benefit. It tells the team what success looks like and helps the Product Owner decide what comes first.
| Part | ❌ Weak | ✅ Better |
|---|---|---|
| Who | As a user… | As a parent paying school fees… |
| What | …I want a dropdown with saved cards on the payment page… | …I want to pay with a card I have used before… |
| Why | …so that I can pay. | …so that paying each term takes seconds, not a hunt for my wallet. |
Bill Wake proposed INVEST in 2003 as a quick test of whether a story is ready to work on. Run every story past these six letters before it goes into a Sprint.
Stories that depend on each other must be done in a fixed order, which makes planning rigid.
Fails: "Story B only works once story A is finished."
Fix: combine them, or split differently so each one delivers something usable.
A story is a starting point for a conversation, not a contract with every detail fixed.
Fails: the story already specifies the screen layout and the database table.
Fix: keep the need, drop the design. Decide the details together.
Every story should deliver something someone outside the team would notice and care about.
Fails: "As a developer, I want to create the database tables."
Fix: slice vertically so each story includes the bit of database, logic and screen it needs.
If nobody can guess how big it is, something important is still unknown.
Fails: "Integrate with the new payment provider", when nobody has seen their API.
Fix: run a short, time-boxed spike to learn, then write the story.
Small stories flow through the board quickly and give feedback early. Aim for several finished per Sprint.
Fails: "As a patient, I want to manage my appointments."
Fix: split it. See Part 5.
If you can't say how to test it, you can't say when it is finished.
Fails: "…so that the app feels faster."
Fix: add acceptance criteria: "results appear within 2 seconds for 95% of searches."
| Check | Result |
|---|---|
| Independent | ✅ Uses existing appointment data. Doesn't need another story first. |
| Negotiable | ✅ Doesn't say how the list looks. A filter on the existing schedule might be enough. |
| Valuable | ✅ Empty slots get filled, so more patients are seen and less income is lost. |
| Estimable | ✅ The team knows the appointment data well. |
| Small | ✅ A few days of work. Contacting waiting patients is a separate story. |
| Testable | ✅ Yes, with the acceptance criteria in Part 4. |
Acceptance criteria are the conditions a story must meet to be accepted. They are agreed in the conversation, written on the story, and checked before it counts as done. A popular format is Given / When / Then: a starting situation, an action, and the expected result.
Big ideas usually start too large to finish in a Sprint. A story that big is often called an epic. The aim is to cut it into small stories that each still deliver something real: thin slices through the whole cake, not separate layers. The slicing and sizing article covers the technique in more depth.
A good goal, but far too big: it covers choosing a doctor, finding a time, confirming, paying, reminders, cancelling and rescheduling. Here it is broken down:
| Split by… | How it works | From the booking epic |
|---|---|---|
| Workflow steps | One story per step of the user's journey. | See slots → book → get confirmation |
| Simple case first | Build the simplest version, then add the variations. | One GP this week first, then any doctor, any clinic, any date |
| Happy path, then exceptions | Make it work when all goes well, then handle problems. | Book a free slot first. "Slot taken while you were booking" comes next. |
| Operations | Create, change and remove are often separate stories. | Book, cancel and reschedule |
| User roles | Different people may need different versions. | A patient books for themselves, then a parent books for their child |
| Business rules | Each rule can be its own story. | "Cancel up to 24 hours before" and "no more than 2 bookings a week" |
| Quality later | Make it work, then make it fast or polished. | Basic slot list first, then "results in under 2 seconds" |
Don't split by layer. "Story 1: database. Story 2: back end. Story 3: screens." None of these gives a patient anything until all three are finished, so it fails the V in INVEST. Each story should cut through every layer it needs.
| # | User story |
|---|---|
| 1 | As a patient, I want to see free slots for my usual GP this week, so that I can pick a time that suits me without calling. |
| 2 | As a patient, I want to book a free slot and get a confirmation email, so that I know my appointment is secured. |
| 3 | As a patient, I want to cancel my booking up to 24 hours before, so that I'm not charged for a visit I can't make. |
| 4 | As a patient, I want to move my booking to another free slot, so that I don't have to cancel and start again. |
| 5 | As a patient, I want to get an SMS reminder the day before, so that I don't forget my appointment. |
| 6 | As a patient, I want to choose any doctor at any of the group's clinics, so that I can be seen sooner when my GP is fully booked. |
Story 2 combines booking and confirming on purpose. A booking with no confirmation leaves the patient unsure it worked, so on its own it wouldn't be valuable.
Good stories from different kinds of products, each with its key acceptance criteria. Notice how each one names a real person, describes the goal without the design, and gives a reason that matters.
| ❌ Weak story | What's wrong | ✅ Better |
|---|---|---|
| "As a user, I want a dashboard." | Vague who, unclear what, no why. | As a sales manager, I want to see this week's deals that are at risk, so that I can step in before they are lost. |
| "As a developer, I want to set up the database." | A technical task with no user value. | Make it part of the first story that needs it. If it truly stands alone, keep it as a plain task, not a story. |
| "As a customer, I want a blue Submit button at the bottom right." | A design decision, not a need. Not negotiable. | As a customer, I want to send my form without scrolling back up, so that I don't miss the last step. |
| "As an admin, I want to add, edit, delete and export users." | Four stories in one. Not small. | Split into four: add, edit, remove and export, each with its own why. |
| "As a shopper, I want a faster checkout." | Not testable: how fast is fast? | Same story, plus the criterion "checkout completes in 3 steps or fewer, under 60 seconds for a returning customer". |
| "Payment page" | Just a label, not a story. No who, what or why. | Write the need behind it, for example the school-fees story in Part 2. |