User Story Template (2026): The Format, Examples and a Copy Block

You don't need to be a developer to use one. It's a short, plain way of asking for work that forces you to say who it's for and why it matters before anyone starts building, designing or writing.

Atlassian's page, as of Nov 2026, describes the standard format and gives it a clear job: after reading a story, the team should know why they're building something, what they're building and what value it creates.

The sentence, broken into parts

Here's each part of the template, what to write in it and what it's doing there. The examples come from Atlassian's own page.

Part	What to write	Example	Its job
As a	The person you're doing this for. Atlassian wants a persona the team understands, not only a job title	As a shopper	Keeps the work pointed at a real person
I want	What they're trying to achieve, with no mention of screens or buttons	I want to save items to a wishlist	States the intent and leaves the solution open
So that	The bigger benefit behind the request	so that I can purchase them later	Explains why the work's worth doing
Acceptance criteria	The checks that tell you the story's complete	How the wishlist should function	Makes the story testable

Atlassian gives a few more one-liners worth reading for the tone: "As Max, I want to invite my friends, so we can enjoy this service together" and "As a project manager, I want to generate a project status report so that I can share progress with stakeholders." Each one's short enough to fit on a sticky note, and none of them says how the thing should be built.

Copy this into your backlog

Paste this into whatever you use to track work, from a task tool to a shared document. Write it in words anyone in the business can read.

Copy this user story template

USER STORY
Title, in a few words:
As a (who this is for):
I want (what they're trying to achieve):
So that (the benefit to them):

ACCEPTANCE CRITERIA
This is done when:
This is done when:
This is done when:

CONVERSATION NOTES
What we agreed when we talked it through:
Tasks and who's responsible for each:
Written by, and date:

Filling it in, one step at a time

1. Pick the user. Atlassian says customers don't have to be external. They can be colleagues inside your organisation who depend on your team. If there are several types of user, Atlassian suggests writing a separate story for each.
2. State the goal. Describe what they want to achieve and keep the solution out of it. Atlassian's test is blunt: if you're describing part of the interface and not the user's goal, you've missed the point.
3. State the benefit. Ask how this fits their bigger picture. If you can't finish the "so that" part, it's worth asking why the work's on the list.
4. Add the acceptance criteria. Atlassian says a story is generally done when the user can complete the outlined task, and tells you to define exactly what that means.
5. Talk it through. Sit down with the people doing the work. Atlassian says this is where the team discusses requirements and functionality, and adds what's agreed to the story.
6. Check the size. Atlassian says a story should fit into one sprint. If it might take weeks or months, break it up or treat it as an epic.
7. Make it visible. Once the stories are defined, Atlassian says they should be visible to the whole team.

The part most teams leave out

A user story isn't a mini-spec, and this is where people go wrong. Atlassian says stories are a few sentences in simple language that don't go into detail, and that requirements are added later, once the team has agreed them. It also warns against thinking of stories as software system requirements.

That's easier to see in what Atlassian calls the 3 C's: Card, Conversation and Confirmation. The Card is the written story. The Conversation is the discussion that clarifies the details. Confirmation is the acceptance criteria that define when the story's complete.

So the sentence you've written is only a third of the job. It's a prompt for a conversation, not the end of one. From what Atlassian describes, my read is that the arguments about scope at review come from teams writing the Card and then jumping straight into the work. If nobody talked it through and nobody agreed what done means, each person's left with their own version of it.

Acceptance criteria without the jargon

Think of these as a short list of yes or no checks. Atlassian says they help the team understand what success looks like and make the story testable. Its own example is the shopper's wishlist story, with criteria spelling out how the wishlist should function.

Here's an illustration I've made up for a marketing team, so you can see the shape of it outside software:

• Story: as a sales rep, I want a one-page summary of the new offer, so that I can answer customer questions on calls.
• Done when the summary fits on one page.
• Done when it lists who the offer's for and what's included.
• Done when the sales lead has read it and agreed it.

Each check's either true or it isn't. If a criterion could start an argument, such as "looks good", rewrite it.

Stories, epics and initiatives

You'll see these three words together, and Atlassian separates them by size. Stories are small, sprint-sized tasks. Epics group related stories under a larger goal. Initiatives hold several epics.

Atlassian adds some useful scale. Teams commit to stories within a sprint of one or two weeks, and they often have two or three epics they're trying to finish each quarter. It also says not every user story needs to be part of an epic, so don't invent one for tidiness. If you're setting goals at that higher level, OKRs are one common way of doing it, and if you're choosing software to hold it all, it's worth seeing how monday dev is set up.

Is it worth the effort?

The downside first. It's easy to churn out "as a user, I want" sentences that follow the format and say nothing. Atlassian admits that stories can seem like an added step to teams who are new to Agile. A vague story written quickly won't save anyone any time.

The pro is that stories keep attention on the person, not the task list. Atlassian's comparison is that a to-do list keeps a team focused on ticking things off, while a set of stories keeps it focused on solving problems for real users. Whoever picks up the work later can also see why it exists.

Where I'd use one

Atlassian writes about software teams, so this next bit is my view, not theirs: I'd use the same format for marketing and operations requests too. It stops "can you make a landing page" arriving with no reason attached. I'd keep each story to one sentence plus three or four checks, have the conversation in person, and skip the long specification until the team's agreed what's needed.

Frequently asked questions

What is the user story format?

Atlassian gives the standard format as: as a user, I want a goal, so that a reason. In plain terms, it says who it's for, what they want and why they want it.

What are acceptance criteria?

They're the conditions that define when a story's complete. Atlassian says they show what success looks like and make the story testable.

What is the difference between a user story and an epic?

Size. Atlassian describes stories as small, sprint-sized tasks, and epics as a group of related stories under a larger goal. Not every story needs an epic.

How long should a user story be?

A few sentences in simple language, according to Atlassian. In terms of work, it should be small enough to finish in one sprint, and if it isn't, you should break it up.

What are the 3 C's of user stories?

Card, Conversation and Confirmation. Atlassian says the Card is the written description, the Conversation clarifies the details, and Confirmation is the acceptance criteria.

Who writes user stories?

Atlassian says a story's generally written by the product owner, product manager or program manager and then submitted for review. In a small business, I'd let whoever's asking for the work write the first draft.