How to Write User Stories in Jira (With Examples)
User stories are the fundamental unit of work in agile teams using Jira. A well-written user story describes a feature from the user's perspective, includes testable acceptance criteria, and is small enough to complete in a single sprint.
This guide covers how to write user stories in Jira with practical examples, acceptance criteria formats, and the most common mistakes to avoid.
Step-by-step guide
Step 1: Use the standard user story format
Write stories in the format: "As a [user type], I want to [action], so that [benefit]." This format forces you to think about the user, what they need, and why it matters. Example: "As a workspace admin, I want to set custom roles for team members, so that I can control who can edit versus view projects."
Step 2: Add acceptance criteria
Below the user story, add a bulleted list of acceptance criteria. Each criterion is a testable condition. Example: "Admin can create a custom role with a name and description. Custom roles appear in the member invitation dropdown. Removing a custom role reassigns members to the default role."
Step 3: Set estimation
Use story points or T-shirt sizes. Points (1, 2, 3, 5, 8) represent relative complexity, not hours. A 2-point story should take roughly twice the effort of a 1-point story. Avoid estimating in hours; it creates false precision.
Step 4: Link to the parent epic
Every user story should belong to an Epic. This creates traceability from the roadmap to individual stories. Use Jira's "Epic Link" field to associate stories with their parent Epic.
Step 5: Add context and design links
In the description, add links to relevant PRDs, Figma designs, and technical docs. Engineers should not need to ask "where is the design?" or "what was the PM thinking?"
Step 6: Define sub-tasks if needed
If a story involves multiple disciplines (frontend, backend, QA), create sub-tasks for each. This allows parallel work and individual assignment without splitting the user story itself.
Common mistakes
Writing technical tasks as user stories
"Refactor the authentication service" is a task, not a user story. User stories describe user-visible behavior. Technical work should be tracked as Tasks or Subtasks, not Stories.
Stories too large to complete in one sprint
If a story is estimated at 8+ points, split it. Large stories create estimation uncertainty, block the sprint, and make progress hard to track. A good story is completable in 1-3 days.
Missing acceptance criteria
A story without acceptance criteria is undefined work. Engineers build what they think "done" means, which may not match what the PM intended. Always include testable criteria.
Vague "so that" benefit
"So that the feature works" is not a benefit. The benefit should describe the user outcome: "so that admins can restrict access to sensitive financial reports."
Tips
- Keep stories independent so they can be reordered without breaking dependencies
- Use Jira custom fields to track story maturity (needs AC, needs design, ready for dev)
- Review stories with engineering before sprint planning to catch ambiguities early
- Write acceptance criteria from the user's perspective, not the implementation perspective
How Vantage helps
Vantage can generate user stories and tickets automatically from PRD requirements. Each generated ticket includes acceptance criteria derived from the PRD, dependency relationships with other tickets, and wave assignments for sprint planning. This removes the manual translation from PRD to user stories in Jira.