User Story Template With Acceptance Criteria (Free)

A user story template does two jobs. It makes every story answer the same three questions (who, what, why), and it gives the team a fixed place to write down how they will know the story is done. This page gives you both: the one-line story format, a full card template you can copy, acceptance criteria in three formats, a definition of ready and done, and worked examples.

If you are new to user stories, start with our guide on how to write user stories, then come back here for the template.

The one-line user story template

Most teams use the format that came out of the Connextra team in London in 2001 and was popularized by Mike Cohn's book User Stories Applied (his overview of user stories is a good primer):

As a [type of user], I want [an action or capability], so that [a benefit or outcome].

Each part does a specific job:

• “As a” names a real kind of user, such as a first-time buyer, an account admin or a returning patient. “As a user” tells the team nothing. If you have personas, use their names.
• “I want” describes what the user does or gets, in their words. It should not describe the solution (“a dropdown”, “a Redis cache”); leave room for the team to find the best one.
• “So that” states the value. This is the part most often skipped and the one that matters most: it is how the team can propose a simpler option that delivers the same outcome, and how the product owner decides priority.

Keep in mind that the sentence is not the requirement. Ron Jeffries described a story as three things: the card, the conversation and the confirmation (the 3 Cs). A template helps with the card and the confirmation (the acceptance criteria); nothing replaces the conversation.

The full user story card template

The one-liner is enough for a sticky note. In a backlog tool you usually need a few more fields so the story can be ranked, estimated and tested. These are the fields we find useful; drop any your team never reads.

Keep “Context and notes” short: if it turns into a page of specification, the story is probably an epic and needs splitting (our story mapping guide shows how).

Copy-ready user story template

Paste this into the description field of a Jira or Linear issue, a Notion database template, or the header row of a spreadsheet. Replace the bracketed text and delete lines you do not use.

• ID: [PROJECT-000]
• Title: [Verb + object, for example “Export invoices to CSV”]
• Story: As a [type of user], I want [action or capability], so that [benefit].
• Context: [Why this matters now; link to research, support tickets or metrics]
• Acceptance criteria: [3 to 7 testable conditions, in checklist or Given/When/Then form]
• Out of scope: [What this story deliberately does not cover]
• Designs: [Link to the frame or prototype]
• Dependencies: [Other stories, services or decisions]
• Priority: [Must / Should / Could, or backlog rank]
• Estimate: [Points or size, filled in by the team]
• Open questions: [Anything that must be answered before the sprint starts]

The “Out of scope” line saves arguments: writing “does not include SMS reset” on the card beats discovering in the sprint review that someone assumed it did.

What acceptance criteria are, and who writes them

Acceptance criteria are the conditions a story must meet to be accepted by the product owner. They describe observable behaviour from the user's point of view, not how the code works. Good criteria are:

• Testable: someone can say yes or no without interpreting. “Fast” is not testable; “results appear within two seconds” is.
• Specific to this story: rules that apply to every story (code reviewed, deployed to staging) belong in the definition of done, not here.
• Free of implementation detail: say what happens, not which component or table makes it happen.
• Honest about failure: at least one criterion covers invalid input, no network or missing permissions.
• Few: three to seven criteria is a healthy range. More than ten usually means the story should be split.

The product owner is accountable for the criteria but should not write them alone. The most reliable pattern is a short refinement conversation between product, a developer and a tester (often called the “three amigos”): what is the value, how will this be built, how could it break.

Format 1: checklist acceptance criteria

A plain list of conditions. It is the fastest format to write and read, and it works well for simple stories and for teams that test manually.

Story: As a returning customer, I want to reset my password by email, so that I can get back into my account without contacting support.

• The login screen has a “Forgot password?” link that opens the reset form.
• Submitting a registered email address sends a reset link within one minute.
• The reset link works once and expires after 30 minutes.
• The new password must meet the existing password rules, and the form says which rule failed.
• After a successful reset, all other sessions for that account are signed out.
• Submitting an unregistered address shows the same confirmation message as a registered one, so the form does not reveal who has an account.

Use the checklist when the behaviour is straightforward. Its weakness is that it hides the starting state and the order of events, which the next format makes explicit.

Format 2: Given/When/Then (Gherkin) acceptance criteria

Given/When/Then comes from behaviour-driven development, which Dan North described with Chris Matts in Introducing BDD. Each scenario states a starting context (Given), an action (When) and an expected outcome (Then). Gherkin is the structured version of this language used by Cucumber and similar tools, so scenarios written this way can become automated tests with little rewording.

Here is the same password reset story as three scenarios, including two unhappy paths.

Scenario 1: reset with a valid link

• Given I have an account registered to anna@example.com
• And I have requested a password reset
• When I open the reset link within 30 minutes and enter a new password that meets the rules
• Then my password is changed
• And I am signed in
• And my other sessions are signed out

Scenario 2: the link has expired

• Given I requested a password reset more than 30 minutes ago
• When I open the reset link
• Then I see a message that the link has expired
• And I am offered a button to send a new link

Scenario 3: the email address is not registered

• Given no account exists for sam@example.com
• When I request a password reset for sam@example.com
• Then I see the same confirmation message a registered user sees
• And no email is sent

When one scenario needs to run with several inputs (say, a list of passwords that should be rejected), Gherkin's Scenario Outline lets you write it once and list the inputs in an examples table.

Keep Gherkin readable: one behaviour per scenario, and write declaratively (“When I request a reset link”) rather than click by click (“When I click the Send button”), so the scenario survives a redesign.

Format 3: rule-based acceptance criteria

For stories that are mostly business rules (pricing, eligibility, validation, permissions), state the rules directly and add scenarios only for the tricky combinations.

Story: As a shopper, I want to apply a discount code at checkout, so that I pay the promotional price.

• Rule 1: one code per order.
• Rule 2: a percentage code applies to the product subtotal only, not to shipping or tax.
• Rule 3: a code with a minimum spend applies only when the subtotal, before the discount, meets the minimum.
• Rule 4: expired or used-up codes are rejected with a message that says why.
• Rule 5: removing items so the subtotal drops below the minimum removes the code and shows a notice.

You can mix formats in one story. A common pattern is rules for the logic plus two or three Given/When/Then scenarios for the cases people are most likely to misread.

Definition of ready vs definition of done

Acceptance criteria are specific to one story. The definition of ready and the definition of done are team-wide agreements that apply to every story.

The Scrum Guide defines the definition of done as the formal description of the state of the Increment when it meets the quality measures required for the product. The definition of ready is not part of Scrum; it is a practice many teams adopt to stop half-understood work entering a sprint (see the Agile Alliance glossary on definition of ready and definition of done).

Sample definition of ready

• The story follows the template and the “so that” is filled in.
• Acceptance criteria are written and reviewed by product, development and testing.
• Designs are linked, or the team agreed none are needed.
• Dependencies are done or scheduled.
• The team has estimated it, and it fits in one sprint.

Sample definition of done

• All acceptance criteria pass.
• Code is reviewed and merged to the main branch.
• Automated tests cover the new behaviour and the full suite passes.
• Basic accessibility checks pass (keyboard use, labels, contrast).
• It is deployed to staging and the product owner has accepted it.

Treat the definition of ready as a checklist for refinement, not a gate. If a team refuses every story that misses one box, work slows down and the conversation the story was meant to start never happens.

Worked examples

Two more stories from different kinds of product. For forty more, see our user story examples.

SaaS: invite a teammate (checklist)

As a workspace admin, I want to invite a teammate by email, so that they can see our projects without me sharing my login.

• Admins see an “Invite” button on the members page; other roles do not.
• The admin can choose the role (Member or Admin) before sending.
• The invite email arrives within one minute and the link is valid for seven days.
• Inviting an address that is already a member shows a message instead of sending a second invite.

E-commerce: save an item for later (Given/When/Then)

As a shopper who is not ready to buy, I want to move an item from my cart to a saved list, so that I can find it again without it affecting my order total.

• Given I am signed in and have two items in my cart
• When I choose “Save for later” on one item
• Then that item moves to my saved list
• And my cart total is recalculated without it
• Given I am not signed in
• When I choose “Save for later”
• Then I am asked to sign in, and the item is saved once I do

Using the template in Jira, Linear, Notion or a spreadsheet

In Jira, use the Story issue type and paste the template into the description (or keep acceptance criteria in a dedicated field if your admin has added one). In Linear, save it as an issue template. In Notion, put it in a database template so new backlog pages open pre-filled. A spreadsheet with one row per story works for a first backlog or a workshop, but move to a tracker once several people edit it. Whatever the tool, keep the template short enough that people fill it in.

Drafting stories and acceptance criteria with AI

Language models are good at a first draft of stories and criteria. A prompt that works:

You are a product manager. For the feature below, write user stories in the format “As a [user], I want [action], so that [benefit]”. For each story, add 3 to 6 acceptance criteria in Given/When/Then form, including at least one unhappy path. List any assumptions and open questions separately. Feature: [describe the feature, the users and any constraints].

Then review the draft like any other input:

• Is the user a real segment you have talked to, or a generic “user”?
• Did the model invent business rules, limits or numbers? Replace them with your own.
• Are the unhappy paths the ones your users actually hit? A draft never replaces the refinement conversation.

Frequently asked questions

Want a team to turn your stories into working software? Bring your backlog, or just the idea, and we will help you shape it into sprint-sized stories and build it. See our monthly development plans.