User Story Templates Examples

The standard user story template is: As a [type of user], I want to [do something] so that [benefit]. Acceptance criteria are usually written as Given [context], when [action], then [outcome]. Below are both templates plus more than fifty worked examples across ecommerce, SaaS, mobile, banking, healthcare, travel, learning platforms and internal tools, written so you can adapt them directly.

Key Highlights

• The three part template exists to force a user, an action and a reason. A story missing the reason is a task.
• Acceptance criteria in Given, When, Then format make a story testable, which is what turns it from a description into something finishable.
• User stories are a placeholder for a conversation rather than a specification. The card is the smallest part of the practice.
• Examples are more useful than rules. Most teams write better stories after seeing twenty than after reading a definition.
• The most common mistake is writing the solution into the story, which removes the team's ability to propose a better one.
• Technical work and defects can use the same format, and forcing it produces awkward stories, so alternative templates are given below.

The Standard Template

Three parts, each doing a specific job.

As a [type of user] names who benefits. Be specific. As a returning customer is more useful than as a user, because it tells the team something about context and expectations.

I want to [do something] names the capability, not the implementation. Filter search results is a capability. Add a dropdown with six options is an implementation, and writing it that way removes the team's ability to propose something better.

So that [benefit] names why it matters. This is the part most often dropped and the most valuable. If nobody can complete it, the item may not be worth building, and discovering that before development is cheap.

A worked example:

As a returning customer, I want to reorder a previous purchase in one step so that I do not have to search for the same items again.

That is the whole card. The three Cs of user stories, named by Ron Jeffries in 2001, describe why it stays short: the Card is a placeholder, the Conversation is where the detail lives, and the Confirmation is how you know it is done. Teams that try to make the card carry all three end up with specifications.

If you are working through the framework this sits inside, our free CSM practice test covers it quickly.

Acceptance Criteria Template

The story says what and why. Acceptance criteria say how you will know it is finished.

Given [the starting context], when [the action happens], then [the expected outcome].

For the reorder story above:

Given I am signed in and have a completed order in the last twelve months, when I select reorder on that order, then all available items are added to my basket.

Given an item from that order is no longer available, when I select reorder, then the available items are added and I am told which were not.

Given I am not signed in, when I view a past order, then I am prompted to sign in before reordering.

Three criteria, each testable, each covering a different path. That last one matters: most stories need a criterion for the unhappy path, and stories that only describe success are the ones that come back.

Acceptance criteria are also where the Definition of Done and the story meet. The Definition of Done applies to every item; acceptance criteria are specific to this one.

Ecommerce Examples

SaaS and B2B Examples

Mobile App Examples

Banking and Fintech Examples

Healthcare Examples

Internal Tools and Admin Examples

Travel and Booking Examples

Learning Platform Examples

Splitting a Story That Is Too Big

The most useful skill after writing them, shown with a worked example.

Take this story: as a customer, I want to manage my subscription so that I can change my plan when my needs change.

That is an epic wearing a story's clothing. Manage covers upgrading, downgrading, pausing, cancelling, changing payment method and changing billing date. It will not finish in a Sprint and nobody can estimate it.

Split by user action, which is usually the most productive axis:

Five stories, each finishable, each independently valuable. Note what the split reveals: upgrading is small and directly increases revenue, while pausing is medium and mostly retention. Those belong in different places in the backlog, which the original single story concealed entirely.

That is the point people miss about splitting. It is a prioritisation activity as much as a sizing one, and it frequently shows that the valuable part of a large item is small and the rest can wait. How that ordering then works is covered in our guide to prioritising user stories.

Other axes worth trying when user action does not work: by data type, by happy path first with edge cases later, by platform, or by a simple version now and a configurable version later.

Templates for Work That Does Not Fit

Forcing every item into the user story format produces awkward results. Three alternatives worth using.

Technical enabler. In order to [outcome], we need to [technical work].

In order to support the catalogue expansion, we need to migrate the search index to the new cluster.

Defect. Given [context], when [action], then [wrong outcome] instead of [expected outcome].

Given I have items in my basket, when I sign in, then the basket is emptied instead of being preserved.

Spike. Question: [what we need to know]. Timebox: [duration]. An answer looks like: [what you will produce].

Question: can our current search index return results for two million records within four hundred milliseconds. Timebox: two days. An answer looks like a benchmark against representative data plus a recommendation.

The general principle is that the user story format exists to keep the user in view. Where there is genuinely no user facing outcome, using a format that fits is better than inventing a fictional user. Writing as a developer, I want to refactor the payment module fools nobody.

What Makes a Story Good

Six qualities, usually remembered as INVEST.

Independent. Can be built without waiting on another story where possible.

Negotiable. Describes what and why, leaving how open for discussion.

Valuable. Delivers something someone notices. If nobody would miss it, question it.

Estimable. The team can size it. If they cannot, it needs splitting or a spike.

Small. Finishable comfortably within a Sprint, ideally a few days.

Testable. Has acceptance criteria that give a clear yes or no.

The two that catch most stories are small and testable. An item that takes most of a Sprint carries more risk and surfaces problems later, and approaches to splitting are covered in our guide to product backlog breakdown strategies. An item without testable criteria will produce disagreement about whether it is finished.

Common Mistakes

Writing the solution instead of the need. Add a dropdown filter rather than filter results. Removes the team's ability to propose something better.

Dropping the so that. Leaves nobody able to judge whether the item is worth building or how to reduce it if needed.

Using as a user for everything. Says nothing. Which user, and what do they know or expect?

Stories that are really epics. Anything spanning several Sprints belongs in the epic category and needs breaking down, and the distinction between the levels is covered in our guide to epic, feature and user story.

Acceptance criteria that only describe success. Real systems fail. A story without an unhappy path criterion usually returns.

Treating the card as a specification. The card is a placeholder for a conversation. Detail that belongs in the conversation should not be crammed into three lines, and this is the mistake that turns refinement into documentation review, as discussed in our guide to backlog refinement.

Writing them alone. A Product Owner producing stories in isolation gets stories that miss technical constraints. The conversation is the point.

Where Stories Come From

Worth a note, because a page of templates can imply stories are authored rather than discovered.

The best stories come out of refinement, where the Product Owner brings an intent and the Developers ask questions that reshape it. A story written at a desk and presented as finished skips the step where it improves.

That has a practical consequence for anyone facilitating. The measure of a good refinement session is not how many items were documented but how many changed as a result of the discussion. A session where every item survived unaltered usually means the conversation did not happen.

For anyone running those sessions, CSM Certification Training covers refinement and the facilitation that makes it produce better items rather than tidier ones.

Closing Thoughts

The template is the easy part. Most teams learn the three part format in an afternoon and then spend a year writing stories that are too large, describe solutions, or lack a testable definition of finished.

The two habits worth building are keeping the so that clause honest, since it is what tells you whether an item deserves to exist, and writing acceptance criteria that cover a failure path, since that is where the disagreements about done actually come from.

Beyond that, treat the card as the start of a conversation rather than the deliverable. The format exists to make sure the right conversation happens, and a beautifully written story that nobody discussed is worth less than a rough one that produced ten minutes of useful disagreement in refinement.

If you are the person facilitating those conversations, CSM Certification Training covers the framework and the refinement practices that turn a backlog of items into something a team can actually work from. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to check your grounding first.