Picking the format before you write the ticket
The four bodies on this page are not four house styles for the same ticket. They answer different questions, and reaching for the wrong one is how a backlog turns into a filing system nobody consults.
Write a user story when the persona changes the answer
“As a project admin” and “as a read-only viewer” lead to different screens, different permissions and different tests. That is when naming a persona earns its line. If every role in your product would want the thing in the same way, the persona is decoration, and what you have written is “as a user” with extra syllables.
Write a job story when your personas are fiction
Most personas were invented in a workshop two years ago and have not been checked since. The job story drops them and leads with the situation instead: when this happens, I want to do this, so I can get that. Nobody has to agree on who Marketing Mary is to agree that “when I am pasting a spec the night before planning” is a real moment that recurs.
The trade is real. You lose the ability to slice a backlog by role, which matters on permission-heavy products where “admin can, member cannot” is half the work. The body also asks for a functional job and an emotional job; the emotional line is the one teams skip and the one that changes designs — “confident that nothing was created without my seeing it” is why a preview screen exists. On infrastructure work it is noise. Delete it there rather than filling it in.
Write an epic when the work shares one success metric
The epic body asks for a business problem, a goal, success metrics, scope, out of scope, dependencies and stakeholders. The section that decides whether you actually have an epic is Success Metrics. If you cannot name a number that moves when the whole thing lands, you do not have an epic — you have a label that groups tickets, and Jira already has labels.
Write a spike when you cannot write the acceptance criteria
That is the entire test. If you can state what done looks like, skip the spike and write the story. A spike buys information, and the price is a timebox agreed before anyone starts.
A spike with acceptance criteria is not a spike. It is a story someone is afraid to estimate. Look at the Done When section of the body below: questions answered with evidence, findings documented, recommendation made. All three are about the document, not the product. If your spike says it is done when the caching layer works, you have written a story and hidden it behind a research label — and you will find that out at review, when there is nothing to demo and the timebox is spent.
“As a user, I want a button, so that I can click it”
That sentence passes every format check and carries no information. It is the most common line in agile backlogs, and the failure is almost always in the third clause.
The “so that” has one job: to be the part you can argue with. A good one names a consequence outside the software — time, money, risk, or a decision somebody can now make. “So that I can click it” restates the second clause. “So that I can export the batch” restates it one noun later. “So that finance gets a reconciled list without re-keying 300 rows” is a claim: it can be wrong, it can be measured, and it tells an engineer what to protect when the obvious implementation turns out to cost three weeks.
A quick test. Cover the middle clause and read the first and third together. If what is left still describes a person with a problem, the story is working. If what is left is “as a user, so that I can use the feature”, delete the ticket and have the conversation instead.
The middle clause has a failure mode of its own: “I want” should name a capability, not a widget. A button, a dropdown and a modal are solutions. A story that names one has quietly handed the design decision to whoever typed the ticket first, and the person who could have designed it properly now has to argue their way out of a written requirement.
Where the epic boundary belongs
This is the most consequential decision on the page and the least discussed. The default failure is drawing epics around document headings: the PRD had four sections, so the board gets four epics. That is a table of contents, not a plan.
Draw the boundary by deliverable. An epic is the smallest amount of work you would be willing to ship and talk about. Three tests, in the order they are useful:
- The metric test. One number should move when the epic lands. If two numbers move independently, that is two epics. If none move, it is a category.
- The announcement test. Could you write one release-note sentence a customer would understand? “Bulk import from CSV” passes. “Q3 backend work” does not.
- The abandonment test. If priorities change halfway, is what already shipped coherent on its own? An epic that is worthless at 50% is usually two epics stacked on top of each other.
The quarter is a scheduling convenience, not a boundary. An epic that happens to take a quarter is fine. An epic sized to fill a quarter is a budget with a name on it.
In Jira this is not only an editorial question. Epic is a real issue type: it drives the roadmap, the epic burndown and every report anyone shows a director. An epic drawn around a document heading does not read badly so much as report badly — the burn-up flattens for six weeks because the single thing on the board cannot be partly delivered.
Splitting: vertical slices, not horizontal layers
“As a user I want the backend” fails because nobody can accept it. Acceptance means a person outside the work can look at it and say yes. A layer cannot be looked at, so a backlog split by layer defers all of its risk into an integration week that nobody estimated.
Splits that hold up:
- By workflow step. Ship create, then edit, then delete. Each one is usable alone.
- By data variation. One file format now, the other four as their own stories.
- By rule. The rule that covers most cases now; the exceptions later, each with its own criteria.
- By interface. The API first, with a command-line call as the acceptance test, then the UI. This is a vertical slice only if the API alone gives somebody something they can use — otherwise it is a layer wearing a costume.
- By quality of service. The manual version now, the automated version once you know anyone wants it.
On estimation: when a story cannot be estimated, the argument is almost never about effort. It is about scope, because two people are estimating two different stories, or about an unknown, which is the spike case above. Reading the story out loud settles more estimation disputes than any scale ever has, and the unit matters far less than whether the same team has used it consistently for more than a quarter.
Acceptance criteria: how much is enough
The body above gives three checkboxes. Three is not a rule, it is a signal. Eleven criteria mean you are describing a workflow and should split the story. Zero criteria mean you have a task rather than a story; write it as a task and move on.
What belongs is anything a second person could check without asking you. What does not belong is implementation: “uses a queue” is a design decision, not a criterion, and “works well” is not checkable by anybody. The Out of Scope section is the most-skipped and most-useful part of the body — one line naming what you decided not to do settles the largest class of arguments at review.
Given / When / Then earns its ceremony when a criterion has branches: an error path, a permission boundary, a state that changes the outcome. It is overhead when the criterion is a single fact, such as the export including the Reporter column. Written as Given / When / Then, that fact takes three lines and says the same thing. Use plain checkboxes until a scenario has a branch worth naming, then switch. The full apparatus — happy path, alternate flow, error handling, edge cases — is the Gherkin scenarios format, which lives in the bug report guide because its natural home is a test suite where the scenarios run.
One more boundary worth keeping straight: acceptance criteria are specific to one story. The checks that apply to every story — reviewed, tested, documented, deployed — belong on a separate list, and copying them onto each ticket is how they drift out of sync. That list is the Definition of Done.
When a story template does not help
If your team is three people sitting in one room, a title and a conversation beat a story template every time, and the template will slowly train you to write things down instead of asking. The format is a protocol for teams that cannot have the conversation: different rooms, different timezones, an audit trail, or a six-month gap between writing the ticket and building it. The overhead is the cost of that protocol. If you are not getting the protocol, do not pay for it.
Three more places it does not help:
- Operational work. “Rotate the certificates before 30 September” has no persona and no benefit clause worth writing. A plain task with a date is better.
- Bugs. “As a user I want the page not to crash” is a parody of the format. Use the bug report guide instead — reproduction steps, expected result, actual result.
- Compliance-driven work. The honest “so that” is “so that the auditor signs off”. That is a real reason and a useless story. Write the requirement and reference the control.
Where the format does start costing real time is volume. Writing one story is a minute of thought. Writing the forty that make up a quarter is an afternoon of retyping the same scaffolding, which is the part worth automating rather than skipping — turning a planning document into a sprint backlog is mechanical work, and the thinking you want to keep is in the third clause, not in the typing.