Short definition
A Jira user story is a single, sprint-sized requirement written from the user's perspective in the form 'As a [persona], I want [capability], so that [outcome].' Stories are the most common child of an epic and the most common parent of a set of sub-tasks. A story should fit in one sprint and have one accountable assignee.
The shape of a good user story
A user story isn’t just a requirement; it’s a negotiable contract between the team and the product owner. The “As a [persona], I want [capability], so that [outcome]” template forces three things to be explicit:
- Persona: who the change is for. Naming “the buyer” or “the admin” rules out features that benefit no real user.
- Capability: what the change does. Phrased as a user action, not an implementation detail.
- Outcome: why it matters. The outcome is the test for whether the story actually shipped.
The story is “done” when the outcome can be observed, not when the code lands. That’s what acceptance criteria on the story (often as Given / When / Then) make concrete.
INVEST and sprint sizing
Most teams check stories against the INVEST heuristic: Independent, Negotiable, Valuable, Estimable, Small, Testable. The “Small” criterion is the most common reason to split a story - if the team can’t finish it inside a single sprint, it’s either an epic in disguise or it has hidden scope that should be extracted into a separate story.
Story points capture the relative size of one story versus the others on the board. Velocity is the sum of story points completed per sprint, used by Jira’s Velocity report and the Epic Burndown to project delivery dates.
Stories, sub-tasks, and the work breakdown
A story sits one level below an epic and one level above its sub-tasks. The sub-tasks under a story usually represent the phases of completing it - design, build, test, document, release - not separate features. This is the part of the work-breakdown that’s most often skipped, and the part STM Issue Templates was built to automate: every new Story ticket creates a uniform sub-task set so the team stops re-typing the same five items every sprint.
See also (Redmoon products)
- User Story template for Jira - A copy-ready Jira user story template with the fields, acceptance criteria, and sub-task list a story should ship with.
- STM Issue Templates - Auto-create the QA / docs / release-note sub-tasks under every new story instead of typing them by hand.
Common questions
What is a user story in Jira?
A user story is a single, sprint-sized requirement written from the user's perspective in the form 'As a [persona], I want [capability], so that [outcome].' Stories are the most common child of an epic and the most common parent of a set of sub-tasks. A story should fit in one sprint and have one accountable assignee.
What's the difference between a story and a task in Jira?
A story describes value to a user (As a buyer, I want saved carts...). A task describes work that may have no direct user value (Migrate the cart table to Postgres). Stories carry acceptance criteria; tasks usually don't. Most agile teams use both - stories for product work, tasks for engineering and operational work.
What fields should a Jira user story have?
At minimum: summary, description (with the As a / I want / So that template), acceptance criteria, story points, sprint, Epic Link, reporter, and labels. Many teams add fields for design link, analytics events, and customer-facing release notes. Put these on the Create Issue screen for the Story issue type so reporters fill them in every time.
Should a user story have sub-tasks?
Most teams split story work into sub-tasks for build, QA, documentation, and release notes. This gives accurate cycle-time data per phase and lets engineering and QA claim work independently. STM Issue Templates removes the manual sub-task typing by creating the full standard set on every new story.