What this template is for
Most teams’ user stories drift into one of two failure modes: a one-line summary with no acceptance criteria, or a 2,000-word description with everything mixed together. Both make estimation impossible and lead to scope arguments mid-sprint.
This template separates concerns across two layers:
- Create-screen fields - the summary states the user benefit. The description holds context. Acceptance criteria live in a dedicated, queryable Jira custom field. Out-of-scope is explicit so scope creep is a conversation, not an assumption. Configure these on the project’s Create Issue screen for issue type Story.
- Definition-of-Done sub-tasks - STM creates the design / tech-design / implementation / tests / feature-flag / analytics / docs sub-tasks on every new Story via an On Create Issue Executor. Delete the ones that don’t apply on each individual story; that’s faster than inventing them every sprint.
When to use it
Use this template for any story that will enter a sprint. Spikes, tech-debt tickets, and bugs do not need this structure - they have their own templates. Reserve the user-story template for changes that deliver visible user value.
If you find yourself fighting the template (cramming a bug-fix into the As-a / I-want / So-that pattern, or making up acceptance criteria for a refactor) you have the wrong template. Pick a different issue type and template instead.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | As a checkout user I want to save my address so that I don't re-enter it next time | Yes |
Description | Background, user benefit, links to research | Yes |
Acceptance Criteria (custom) | Given/When/Then bullets, each independently testable | Yes |
Story Points | 3 | Yes |
Epic Link | PROJ-1023 - Checkout v3 | No |
Components | checkout-web, identity-service | No |
Definition of Done (custom) | Tested, documented, behind feature flag, analytics wired | No |
Out of Scope (custom) | Multi-address support - tracked separately | No |
Designs (custom) | Figma link | No |
Analytics Events (custom) | address_saved, address_used_on_return | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Design review - final mocks approved or noted exceptions
- Tech design - brief written for non-trivial changes; spike if estimate is unclear
- Implementation
- Unit + integration tests
- Behind feature flag with safe default
- Analytics events wired and validated in staging
- Documentation: changelog + internal handoff note
Common questions
What makes a Jira user story 'ready' for sprint planning?
A story is ready when the description states the user benefit, acceptance criteria are written as testable Given/When/Then bullets, dependencies are linked, out-of-scope items are listed explicitly, and the team can give a story-point estimate. If any of those are missing, the story is not ready - it's a wish.
Where should acceptance criteria live on a Jira story?
In a dedicated custom field, not in the description. Keeping acceptance criteria in its own field lets you JQL-search for stories missing criteria, render them in board cards, and reference them in tests. Dumping them at the bottom of the description hides them.
Should user stories have sub-tasks or not?
Sub-tasks help when implementation crosses skill boundaries (design, backend, frontend, analytics). They hurt when they're just a private to-do list for one engineer. Use the template's sub-tasks as a Definition of Done checklist created by an STM On Create Issue Executor; delete the ones that don't apply on each individual story rather than trying to skip them at creation time.
How small should a user story be?
Small enough to finish inside a single sprint with room to spare. INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) is the standard heuristic. If a story is more than ~1/3 of a sprint's velocity, split it - either by user flow or by acceptance criterion.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →