User Story Template for Jira: Copy, Examples & Acceptance Criteria

Use this free user story template for Jira when you need a clear story for backlog refinement, sprint planning, or product handoff. It includes the classic As a / I want / So that format plus business value, acceptance criteria, story points, priority, dependencies, open questions, and Definition of Done.

A good user story explains:

• who needs the work
• what they need to do
• why it matters
• how the team will know it is done

If you want to generate a first draft from rough notes, use the User Story Generator. If you already have a story and need better test conditions, use the Acceptance Criteria Generator.

For the shortest path, paste your feature idea into the generator first, then bring the generated story to backlog refinement for team review and estimation.

How to Use This User Story Template

1. Start with the user and the outcome, not a technical solution.
2. Explain the business value so the team understands why the story matters.
3. Add acceptance criteria that QA and developers can verify.
4. Record scope boundaries, dependencies, and open questions.
5. Estimate the story with the team and confirm that it is ready for the sprint.

Copy-Paste User Story Template

## User Story

As a [type of user],
I want to [perform an action],
So that [I achieve a benefit or outcome].

## Business Value

[Explain why this matters to the user, customer, product, or business.]

## Scope

In scope:
- [What this story includes]
- [Main workflow or behavior]
- [Important constraints]

Out of scope:
- [What this story does not include]
- [Future enhancement or separate story]

## Acceptance Criteria

Given [context or precondition],
When [action happens],
Then [expected result happens].

Checklist:
- [ ] [Criterion 1: clear and testable]
- [ ] [Criterion 2: error state or edge case]
- [ ] [Criterion 3: permission, validation, or data rule]

## Story Points

[ ] 1  [ ] 2  [ ] 3  [ ] 5  [ ] 8  [ ] 13  [ ] ?

## Priority

[ ] Critical  [ ] High  [ ] Medium  [ ] Low

## Dependencies

- [Blocking team, API, design, data, approval, or related ticket]

## Open Questions

- [Question that must be answered before development starts]

## Definition of Done

- [ ] Acceptance criteria are met
- [ ] Code reviewed and approved
- [ ] Tests written or updated
- [ ] QA verified in staging or target environment
- [ ] No known regression introduced
- [ ] Documentation, analytics, or release notes updated if needed

Filled User Story Example

## User Story

As a registered user,
I want to reset my password by email,
So that I can regain access to my account if I forget my password.

## Business Value

Users can recover access without contacting support, reducing support tickets and improving account self-service.

## Scope

In scope:
- User can request a password reset link from the login page
- System sends reset email to a valid account email
- User can set a new password from a valid reset link
- Expired or invalid links show a clear error

Out of scope:
- Changing email address
- Multi-factor authentication recovery
- Admin password reset flow

## Acceptance Criteria

Given I am on the login page,
When I click "Forgot password",
Then I am taken to the password reset page.

Given I enter a valid registered email address,
When I submit the reset request,
Then I receive a reset email within 2 minutes.

Given I open a valid reset link,
When I enter and confirm a new password,
Then my password is updated and I can log in with the new password.

Given the reset link is expired,
When I open the link,
Then I see an error message and an option to request a new link.

Checklist:
- [ ] Reset email does not reveal whether an email exists
- [ ] Reset token expires after 24 hours
- [ ] Password validation rules match account settings
- [ ] Successful reset invalidates the used token

## Story Points

5

## Priority

High

## Dependencies

- Email provider configuration
- Password policy copy from security team

## Open Questions

- Should reset links expire after 15 minutes, 1 hour, or 24 hours?
- Do we need an audit event for successful password reset?

## Definition of Done

- [ ] Reset flow works end to end in staging
- [ ] Unit and integration tests cover valid, expired, and invalid token cases
- [ ] QA verifies happy path and error states
- [ ] Security review completed for token expiry behavior

User Story Format

The classic format is:

As a [user type],
I want [capability],
So that [benefit].

Each part has a job.

The "so that" line is important. Without it, the team may build the requested feature without understanding the outcome.

What to Include in a Jira User Story

A Jira-ready user story should include more than the one-line story.

If the story is still unclear, refine it before sprint planning. Use AI Backlog Refinement Prompts to find missing details and Product Owner questions.

Acceptance Criteria Template

Use Given/When/Then for behavior that needs clear test cases:

Given [starting context],
When [user action or system event],
Then [expected outcome].

Use checklist format for simpler requirements:

- [ ] User can submit the form with valid data
- [ ] Validation message appears for invalid data
- [ ] Empty state appears when no results are available
- [ ] User without permission cannot access the feature

Good acceptance criteria are:

• specific
• testable
• agreed before development starts
• focused on behavior, not implementation
• clear about edge cases and error states

See How to Write Acceptance Criteria for deeper guidance.

Definition of Ready Checklist

Before a user story enters sprint planning, check:

• user or stakeholder is clear
• business value is clear
• acceptance criteria are testable
• scope boundaries are clear
• dependencies are visible
• design or API notes are attached if needed
• story is small enough to estimate
• open questions are answered or tracked

If several items fail this checklist, the story is not ready. Use the Definition of Ready Template.

Story Point Guidance

Story points should include all work needed to call the story done:

• development
• tests
• code review
• QA verification
• documentation or release notes if needed
• deployment or configuration work

Do not estimate only coding time.

Use Story Points Explained if your team needs the basics, or Planning Poker when the team needs to estimate together.

Common User Story Mistakes

Writing from the system perspective

Weak:

As a system, I want to store password reset tokens.

Better:

As a registered user, I want to reset my password by email so that I can regain access to my account.

Technical work may still exist, but the user story should explain user or business value.

Missing the business value

If the story does not explain why the work matters, the team has less context for trade-offs.

Acceptance criteria are too vague

Weak:

User can reset password.

Better:

Given I open an expired reset link, when the page loads, then I see an error and can request a new link.

The story is too large

If a story has many workflows, many user types, or more than 10 acceptance criteria, split it.

Dependencies are hidden

If the story depends on design, another team, an API, data migration, or approval, make that visible before sprint planning.

Frequently Asked Questions

What is the standard user story template?

The standard user story template is: As a [user type], I want to [do something], so that [benefit or outcome]. Good Jira stories also include acceptance criteria, priority, story points, dependencies, and Definition of Done.

Can I paste this user story template into Jira?

Yes. The template uses simple Markdown-style sections that are easy to paste into Jira, Linear, Azure DevOps, or another backlog tool.

How many acceptance criteria should a user story have?

Most user stories need 3 to 7 acceptance criteria. If you need more than 10, the story may be too large and should be split.

Who writes user stories?

The Product Owner usually writes the first draft, but developers, QA, designers, and stakeholders often help refine the story and acceptance criteria.

What is the difference between a user story and a task?

A user story describes user or business value. A task describes implementation work. Teams often break a user story into technical tasks during sprint planning.

Next Step

Use these resources together:

1. User Story Generator - turn rough feature notes into a Jira-ready story.
2. Acceptance Criteria Generator - create testable criteria from a rough story.
3. User Story Examples for Different Domains - compare your story with real examples.
4. AI Backlog Refinement Prompts - find gaps before sprint planning.