User story template for Jira

A Jira Story is a small, self-contained unit of work written from the user’s point of view: who needs something, what they want to do, and why it matters. A user story template fixes that shape across your whole backlog so every Story reads the same way during refinement, planning and code review. Copy the template above straight into a Jira issue, or read on for the As a, I want, so that format, how to write a strong story, acceptance-criteria patterns, estimation, and how to turn the structure into a reusable template with Process Templates for Jira.

What is a user story template?

Instead of starting from a blank Description field, the writer fills a framework that already asks the right questions. The result is a backlog the whole team can read at a glance during refinement, sprint planning and review, and stories that are genuinely comparable when it is time to estimate.

The “As a, I want, so that” format

A good Story answers four questions before anyone writes a line of code: who the user is, what they want to achieve, why it benefits them, and how the team will know it is finished. The classic one-line format carries the first three:

As a <<user type>>, I want <<goal>> so that <<benefit>>.

For example: “As a customer, I want to reset my password so that I can access my account if I forget it.” The user role keeps the team in the right perspective, the goal states the specific task, and the reason gives context that often shapes the solution. Acceptance criteria answer the fourth question and act as the checklist for “done.”

Writing every Story in this format is what makes a backlog scannable: the role, action and benefit always sit in the same place, so refinement conversations stay on the work instead of decoding formatting. It also makes estimation more reliable, because two Stories written to the same shape are genuinely comparable.

Field-by-field breakdown

• Summary. A short, scannable title for the Jira issue, for example “Reset password from the login page.” Keep it terse; the full intent lives in the user story statement.
• User story. The canonical “As a… I want… so that…” statement. This is the line everyone reads first, so it carries the role, the goal and the benefit.
• Description. The relevant context, requirements and constraints. Keep it high-level; if deep technical notes are needed, link a separate technical task rather than overloading the Story.
• Acceptance criteria. Specific, measurable conditions that must be met for the Story to be complete. Phrase each one so it is testable and unambiguous.
• Priority. Where this Story sits against the rest of the backlog, from Highest to Lowest, based on urgency and business value.
• Story points. A relative estimate of effort rather than a number of hours. Exposing this as a dropdown keeps the scale consistent across the team.
• Dependencies. Anything that blocks the Story or must ship first, such as another issue or a shared service.
• Linked tasks. The breakdown of work needed to deliver the Story, optionally with estimates and assignees.
• Design and related issues. A link to the Figma frame, plus the parent epic or sibling Stories so traceability is built in from the start.

How to write a user story

A user story is not a specification. It is a reminder to have a conversation about a slice of user value, captured in a way the whole team reads the same. Start from the one-line format and fill the three blanks honestly: name a real user role, a concrete action, and the benefit that justifies the work. If you cannot state the benefit, question whether the Story belongs in the backlog at all.

A strong Story follows the INVEST criteria:

• Independent. It can be built and shipped without waiting on another Story wherever possible.
• Negotiable. It describes the need, not a fixed implementation, leaving room for the team to find the best solution.
• Valuable. It delivers something a user or the business can perceive.
• Estimable. It is clear enough that the team can size it with reasonable confidence.
• Small. It fits inside a single sprint.
• Testable. Its acceptance criteria can be verified as pass or fail.

Beyond INVEST, a few habits keep a backlog healthy: write from the end user’s perspective rather than as a disguised technical task, always attach acceptance criteria, break large Stories down so each fits a sprint, link every Story to its epic, and groom the backlog regularly so you never build against stale requirements.

Acceptance criteria patterns

Acceptance criteria turn a Story from an intention into something testable. Two patterns cover almost every case.

Given / When / Then (scenario based). Borrowed from behaviour-driven development, it reads as a concrete scenario:

Given a user with an expired session, when they request a password reset, then a reset email is sent within five seconds.

This pattern shines when behaviour depends on context or state.

Rule-oriented checklist. A flat list of conditions that must all be true:

• The reset link expires in 30 minutes.
• The email arrives within five seconds.
• The confirmation page is keyboard accessible.

This pattern is faster to write for straightforward Stories and maps cleanly to a Jira checklist.

Whichever you pick, phrase each criterion so a tester, or an automated test, can mark it pass or fail without interpretation. Avoid words like “fast” or “easy”; state the measurable threshold instead.

For reusable checklists that stand on their own, separate from a single story’s pass-or-fail conditions, see the standalone checklists on the Jira checklist template.

Types of user stories

Not every Story describes a button a user clicks. Most backlogs mix several kinds, and naming the type keeps reporting honest:

• Functional, user-facing stories deliver a capability a user can see, like the password-reset example above. These are the default, and the As a / I want / so that format fits them best.
• Technical or enabler stories carry work that supports user value without being user-facing on its own, such as migrating a service or adding an API. Frame them around the user they ultimately serve and link them to the functional Story they unblock.
• Spikes are time-boxed research stories. The goal is a decision or an estimate, not shippable code, so give them an explicit question and a time limit instead of acceptance criteria.
• Non-functional stories capture performance, accessibility or security requirements, for example “the reset page must be keyboard accessible.” Often these live as acceptance criteria on a functional Story rather than as separate tickets.

Keeping the type explicit, with a Jira label or component, stops technical work from hiding inside vague tickets.

Story points and estimation

Story points size a Story by relative effort, not by hours. The team compares a new Story against ones it has already delivered: if password reset was a 3, a Story that feels twice as involved is a 5 or an 8. Most teams use a modified Fibonacci scale (1, 2, 3, 5, 8, 13) because the widening gaps reflect how uncertainty grows with size.

Points work better than hours because they are quicker to agree on, they stay stable as individuals get faster, and they roll up into velocity, the amount of work a team completes per sprint, which makes forecasting possible. If a Story lands at 13 or above, treat that as a signal to split it; anything that large rarely fits in a sprint and usually hides more than one piece of user value.

Story vs epic vs task in Jira

Jira organises work in a hierarchy, and Stories sit in the middle of it:

• An epic is a large body of work that spans several sprints and groups many related Stories, such as “passwordless authentication.” See the Epic template.
• A user story is a single slice of user value that fits inside one sprint, like “reset password from the login page.”
• A task or sub-task is a unit of execution under a Story, often technical, such as “build the reset endpoint.” See the Task template.

The test is value and size. If it delivers something a user notices and fits in a sprint, it is a Story. If it is too big for a sprint, it is an epic. If it is a step toward a Story with no standalone user value, it is a task. Linking Stories to their epic and breaking them into tasks gives you roll-up reporting from sub-task all the way to initiative.

Common mistakes

• Writing a technical task in disguise. “Add an index to the users table” is not a user story. If there is no user-facing benefit, it is a task; link it to the Story it serves.
• Skipping acceptance criteria. Without them, “done” is a matter of opinion and the Story bounces back in review.
• Stories too big to finish in a sprint. If it cannot be demoed at the end of the sprint, split it. A Story at 13 points or more is a warning sign.
• A missing or hand-wavy benefit. “so that it works better” is not a reason. If you cannot name the value, question whether the Story belongs in the backlog.
• Bundling several needs into one Story. One Story, one slice of value. Several “and”s in the title usually means several Stories.
• Gold-plating the description. A Story is a placeholder for a conversation, not a spec. Keep detail in the acceptance criteria and linked tasks, not in three paragraphs of prose.

Good story vs weak story

A vague Story stalls the team. Compare these two:

Weak: “Improve the login page.” There is no user, no clear goal, no benefit and nothing to test against. Two developers would build two different things.

Strong: “As a returning user who forgot their password, I want to reset it from the login page so that I do not have to email support.” Acceptance criteria: the reset link expires in 30 minutes; the email arrives within 5 seconds; the confirmation page is keyboard accessible. Now the user, the goal, the benefit and the finish line are all explicit, and the Story is small enough to estimate and test.

The difference is not length. It is specificity in the role, the action, the reason and the acceptance criteria.

How to use this template in Jira

1. Save a finished Story as a template. Open a well-written Story in Jira, then save it as a template in Process Templates for Jira so the structure is captured once.
2. Add variables for the parts that change. Turn the user role, the action, the benefit and Story points into variables so the team fills only the blanks at create time.
3. Create the Story from the template. Pick the template, prefill the create screen or skip it entirely, and the description, acceptance-criteria checklist and links are populated for you.
4. Reuse it everywhere. Apply the same template across projects, pull it into refinement with a dashboard gadget, or roll it into an Epic template so a single launch creates the whole set of Stories at once.

Compared with cloning issues by hand, a template carries variables, preserves issue links and works for parent and sub-task hierarchies, so nothing has to be patched up after the fact.

Frequently asked questions

What is a user story template? A user story template is a predefined format that every story follows: the As a, I want, so that statement, acceptance criteria, priority, story points and linked tasks. It keeps the whole backlog consistent so any story can be read at a glance during refinement and planning.

How do you write a good user story? Write from the end user’s perspective using the As a, I want, so that format, keep it small enough to finish in one sprint, and attach clear, testable acceptance criteria. A strong story follows INVEST: independent, negotiable, valuable, estimable, small and testable.

What is the difference between an epic and a user story? A user story is a single small piece of user-facing value that fits in one sprint. An epic is a larger body of work that groups many related stories and spans several sprints. Stories roll up to epics, which roll up to initiatives.

What are story points? Story points are a relative estimate of the effort a story takes, not a count of hours. Teams size stories against each other on a scale such as 1, 2, 3, 5, 8, 13, which keeps estimation consistent and comparable across the backlog.

How do I create a reusable user story template in Jira? Install Process Templates for Jira, save a well-written Story as a template, then add variables for the user role, action, benefit and story points so your team fills only the blanks when creating a new Story.

Related templates

Pair the user story with the rest of your agile workflow: the Task template for the work underneath it, the Epic template for the initiative above it, and the Bug template for defects. Or browse the full template library for matching formats across software, ITSM and support work.