2026년 4월 24일
A practical refresher on writing Jira work your whole team can actually use. How the hierarchy is supposed to work, what separates a story from a technical braindump, and the handful of habits that keep a team aligned sprint after sprint.
약 22분
Most teams that have been running Scrum for a while can break work down just fine. The ticket count goes up. The board looks busy. Work gets finished. And yet, when someone outside the team opens a ticket, they often cannot tell what is actually being shipped or for whom. The information is there, technically. It is just organized for the person who wrote it, not for anyone else who needs to read it.
A few common drift patterns:
None of this is wrong in a "you violated the rules of Jira" sense. It is wrong in a "nobody outside the author's head can use these tickets" sense. Product cannot roadmap from them. Design cannot spot friction. QA cannot verify them. A new joiner has no chance.
This post is a practical refresher on the habits that keep a team's work legible to everyone around it: the hierarchy, the anatomy of a story, sizing, splitting, and the two short checklists that hold the whole thing together. The goal is not process theater. The goal is to write work that survives contact with people other than its author.
First, the mechanical bit. Jira's default hierarchy looks like this:
Atlassian treats Story and Task as peers, both of which can sit under an Epic and both of which can have Subtasks. So technically, yes, you can put Tasks directly under an Epic and Jira will not complain.1 That is not the problem. The problem is what each level is for:
When a team breaks an Epic straight into Tasks and skips Story, two things happen. First, every item becomes a technical chore regardless of whether it actually delivers user value, because "Task" signals "plumbing" to everyone who reads a board. Second, the question "why are we doing this epic at all?" has nowhere to live. The Epic description usually contains one line and a Figma link. The Tasks are implementation. The why evaporates.
Quick self-check
Open your current Epic. Can you read the direct children and answer "what will a user or operator be able to do that they couldn't before?" If the answer comes from the Tasks' implementation notes, you need a Story layer.
Use Task for the chores. Use Story for anything with a user, a customer, an operator, or an internal tool user on the other end. Subtasks go inside. That is the shape.
The single test that catches most bad stories:
If the answer is no, you wrote a braindump, not a story. Both can contain the same information. They are organized differently, because they serve different readers.
A braindump is written by the person who already knows the context, for the person they will be tomorrow when they sit back down at the keyboard. It opens with "Refactor the useAuthController to account for the new session shape from DEV-1234." It is efficient, private, and perfectly fine as a note to self. It is not a story.
A story is a contract between product, design, and engineering. It states the change in terms of the outcome, not the mechanism. The implementation plan belongs in Subtasks, a linked tech-design doc, or a PR description. Keep them separate.
Two common failure modes:
getSession() to use the new cookie helper. 3) Delete the old legacyAuth module." The first is an acceptance criterion. The other two are implementation. Split them.The Connextra template from 2001 is still the fastest way to force a story into shape:2
It looks like a formality. It is not. It forces you to answer three questions you will otherwise skip:
Do not be precious about the wording. Write it in plain prose if you prefer. But if a story cannot answer those three questions somewhere in its body, it is not yet a story.
Ron Jeffries framed the same idea as the 3 C's back in 2001: a story is a Card (short, on a card, because the card cannot hold everything), a Conversation (the details get filled in by talking), and a Confirmation (the acceptance criteria that prove it is done).3 The most important thing on the Card is the intent. The rest is what the conversation and the acceptance criteria are for.
Bill Wake proposed INVEST in 2003 as a checklist for "is this story ready?".4 Two decades later it is still one of the most compact sanity checks available.
| Letter | Meaning | What it catches |
|---|---|---|
| I | Independent | Can this be built without waiting on two other stories? If not, sequence them explicitly. |
| N | Negotiable | Is the how still open, or is the solution already baked into the description? |
| V | Valuable | Who benefits and how? If you cannot answer, you have a Task, not a Story. |
| E | Estimable | Is the scope clear enough that three engineers could roughly agree on size? |
| S | Small | Fits in a sprint. If it does not, split it. |
| T |
The letter most often violated in practice is Testable. Acceptance criteria like "the feature works correctly" or "users can use X" are not testable. They are a vibe. QA needs observable behavior.
Given / When / Then
Dan North's BDD notation still reads as cleanly as it did in 2006. "Given a user with an expired session, When they open the app, Then they see the sign-in screen." Three clauses, no ambiguity, no implementation. You can hand this to QA and walk away.
A bullet list of observable outcomes works just as well. The format matters less than the property: a neutral reader can tell whether the story is done without asking the engineer.
Story points are a source of more team drama than any other single item on the board. Here is the short version.
A small taxonomy that tends to hold up across teams:
| Points | What it usually means |
|---|---|
| 1 | Trivial. Config change, copy tweak, one small bug fix. |
| 2 | Small and well-understood. A few files, one test, no surprises expected. |
| 3 | Medium. Touches one area, one or two edge cases to think about. |
| 5 | Meaty. Cuts across a couple of modules, or has real uncertainty. |
| 8 | Large. Probably wants to be two stories. Accept it if you must, flag it as a risk. |
| 13 | Do not take this into a sprint. Split it, or spike it, or break it into a proper Epic. |
Story splitting is the single most practiced skill on a mature agile team and the most absent one on a drifting team. Get it right and every sprint ships visible progress. Get it wrong and the board fills up with "in progress" tickets that cannot land until three other tickets land first.
When a story is too big, engineers instinctively split it horizontally, by technical layer: a backend story, a frontend story, a migration story, maybe an analytics story. Clean separation, each person owns their lane, everyone understands their piece.
It is the worst possible split.
None of the slices delivers user-visible value on its own. The "two-week story" is still two weeks long. Now it has three times the coordination cost, three separate reviews, and a hard integration step at the end where any slipped piece blocks everything. Nothing ships. Nothing is learned. The team is just as slow, with more meetings.
Horizontal splits fail INVEST on three letters at once
The backend-only slice is not Independent (frontend waits on it), not Valuable (no user benefits from an API nobody calls), and not really Testable from the user's perspective. Three of the six letters violated. If a split breaks INVEST worse than the original story, it is not a split.
The alternative is the vertical slice: a thin, end-to-end cut through the same feature that touches every layer the feature needs (data, logic, UI, any integration), but delivers a smaller piece of user-visible value. Each vertical slice is shippable in isolation. Each teaches the team something about the problem before the next slice starts.
That phrasing, from the Humanizing Work splitting guide, is the most useful mental model for splitting available.6 Every splittable story has an essential behavior and a set of variations layered on top of it: data types, user roles, edge cases, rule permutations, UI richness. Ship the core first. Ship variations as separate stories that can be prioritized, deferred, or dropped on their own merits.
A short preflight before reaching for the splitting patterns:
The Humanizing Work guide collects nine proven splitting patterns. They sit in a rough order from most broadly useful to most specialized. Work down the list; for most stories, one of the first five will produce a clean split.
1. Workflow steps. A story that describes a multi-step process usually splits along those steps. Ship the simplest end-to-end path first, then layer in the intermediate steps as their own stories.
Example. "Editors publish articles through legal and marketing approval." Slice into: publish directly without review; publish with editor review; publish with legal review; publish with marketing review; preview in staging before publish. Five shippable slices, each visible end-to-end.
2. Operations (CRUD). The word "manage" in a story title is almost always a clue: it hides multiple operations behind one verb. "Users manage their account" is really create (sign up), read (view profile), update (edit settings), delete (close account). Four stories, usually with very different priorities.
3. Business rule variations. One feature, many rules. Ship the core rule now; each additional rule is a separate story. "Search flights with flexible dates" might support "within N days of a target," "any weekend in a given month," and "plus or minus N days of a window." Three different rules, three stories, often very different in value and complexity.
4. Variations in data. Start with the simplest data shape the feature needs and add richer data shapes later. A location search ships first supporting countries only, then cities, then neighborhoods. The feature is live end-to-end after slice one; later slices broaden what it handles. Crucially, you often find that later data variations are wanted less than the core, and can be deprioritized.
5. Data entry methods. The UI is doing most of the work, not the underlying logic. Ship the feature with a minimal input first (plain text field, simple form, typed values); the polished interaction (calendar picker, autocomplete, drag-and-drop) is a follow-up. The feature works on day one; it just looks plain.
6. Major effort. The first variation carries all the infrastructure cost; subsequent variations are nearly free once it lands. Credit card processing: implement one card type end-to-end first. Adding the other three is a much smaller story once the payment pipeline exists, and you have learned enough along the way to estimate the remaining work accurately.
7. Simple then complex. During planning, the scope keeps expanding as the team says "yeah, but also what about X?" Capture the simple core as the first story; each "what about X?" becomes its own candidate story that product can prioritize, defer, or drop. This is the cure for scope creep during refinement.
8. Defer performance. If a significant chunk of the estimate is "make it fast" rather than "make it work," split those apart. Ship the correct but slow version first, with a loading state if needed. Optimize in a follow-up story, once you have real usage data pointing at where the time is actually going. Premature optimization wastes estimates.
9. Spike. The explicit last resort. If the team genuinely does not understand the implementation well enough to estimate, time-box a research story. Its acceptance criteria are the questions that need answers. The work of building the feature becomes the story after the spike lands, estimated with real information. Reach for this only when the other patterns do not apply; a spike is not a split, it is an admission that you cannot split yet.
The most common mistake when applying these patterns is stopping at the first workable split. The patterns are not mutually exclusive. Any sufficiently large story can usually be split three or four different ways: by workflow, by data, by rules, by interface. Generate multiple candidate splits, sketch each one on the board, then choose the split that lets product deprioritize the least valuable slices most cleanly.
Two rules of thumb for picking between candidates:
Two or three practices, not a lecture
The fastest way to teach story splitting is not a workshop. Take one real oversized story from the backlog into refinement. Generate three different splits using three different patterns. Have the team vote on which one they would rather ship. Do that exercise twice, maybe three times, across two refinements. Teams pick this up with about two to three hours of deliberate practice, not weeks.
The nine-pattern list is the complete toolbox. But in a live refinement, when a 13-point story is on the board and three people are looking at you expectantly, you want something shorter you can say out loud. That is where Mike Cohn's SPIDR earns its keep.7 Five letters, each one a prompt for a common splitting angle. Not a replacement for the nine patterns; a compressed subset, easier to remember under pressure.
| Letter | Stands for | When to reach for it | Tiny example |
|---|---|---|---|
| Spikes | Research | The team cannot estimate because the implementation approach is unclear | "Investigate which payment providers fit our constraints" (timeboxed) |
| Paths | Workflows | One story covers multiple user journeys or workflow steps | Happy path ships first; error-handling paths follow |
| Interfaces | Input UX | The UI is doing most of the work, not the underlying logic | Plain text input now; autocomplete and typeahead later |
| Data | Scope | The story has to handle different data shapes, ranges, or locales | Ship with country-level data; add city, then neighborhood |
Mapped against the full list: Spikes covers pattern 9, Paths covers 1, Interfaces covers 5, Data covers 4, Rules covers 3. SPIDR hits the five most common situations. It does not cover operations / CRUD (pattern 2), major effort (6), simple-then-complex (7), or defer performance (8). When SPIDR does not produce a clean split, work down the full list.
How to use SPIDR in practice. When a story looks too big, say the acronym out loud and try each letter in order:
You will usually have an answer by the second or third letter. That is SPIDR's value: in a refinement session you do not have ten minutes to work through nine patterns. You have two minutes, and SPIDR will find a split for most stories in that time.
Here is the kind of story that often gets written as a braindump:
Task
AUTH-482
To do
Description
Needs updates in authMiddleware.ts and sessionStore.ts. Depends on
DEV-1234 (new cookie helper). Should also delete the legacy
parseToken path. @mark knows the context. See thread in #squad-auth
from last Thursday.
AC: useAuthController consumes the new session shape, legacy
parseToken path is gone, existing auth tests stay green.
And here is the same work, written as a story:
Story
AUTH-482
To do
Description
As a signed-in user, I want my session to survive reloading or opening new tabs, so that I am not forced to sign in again during normal multi-tab use.
Context
The session token is currently regenerated on every page load, which drops sessions under common multi-tab patterns. Support has flagged this as the top complaint this month.
Acceptance criteria
Out of scope: "Remember me" persistence across browser restarts (separate story).
Subtasks: adopt new cookie helper from DEV-1234; remove the
legacy parseToken path; add integration tests for reload and
new-tab flows.
Same work. Same engineer. Ten minutes more up front. The product manager can now see what is being shipped. QA can verify it. A new joiner reads three bullets and is oriented. Next quarter, when someone asks "why did we touch the auth layer?", the ticket answers for itself.
Two short checklists, one at each boundary of the sprint. They are not ceremony. They are the mechanism that keeps stories from rotting mid-sprint.
Definition of Ready (can this story enter a sprint?)
Definition of Done (can this story leave the sprint?)
Both lists are team artifacts. Write yours together, keep it short, pin it in the team space. Revisit it in a retro every quarter or so. The point is not to have a perfect list. The point is to have a shared list.
None of this is new. Most of the references below are over twenty years old. What is new, for every team, is the constant pressure of drift: new people arrive, old habits fade, the board slowly fills up with tickets written in a private language. The cure is not more ceremony. It is a shared, short, repeatable bar for what a story is and what it needs to contain.
Agree on the rules, not the process. Then do the boring thing consistently, sprint after sprint, and the team's work becomes legible to everyone around it again.
There's a skill for this
INVEST, Connextra, and SPIDR exist as an agent skill that reshapes a draft
ticket and splits oversized stories. Install it with npx skills@latest add saschb2b/skills --skill to-story or read the full to-story
skill.
The canonical reference for how Jira's hierarchy is intended to work, including the peer relationship between Story and Task.
Origin and usage of the Connextra 'As a, I want, so that' template.
The 3 C's of user stories from 2001. Two pages, still essential.
The 2003 article that introduced the INVEST acronym. Short, still the best summary.
The Weber's Law justification for Fibonacci story points, from the person who popularized them.
The most comprehensive treatment of vertical slicing available. Nine patterns, a clear decision flow, and the framing that the whole splitting section of this post is built on. Send it to your team.
A compact five-letter mnemonic (Spikes, Paths, Interfaces, Data, Rules) that covers the most common subset of the Humanizing Work patterns.
Origin of the Given / When / Then format for acceptance criteria.
A current, practical facilitation guide for running a story-writing session as a team.
| Testable |
| Are the acceptance criteria observable by someone who is not you? |
| Rules |
| Logic |
| One feature, multiple business rules stacked on top of it |
| Basic pricing rule ships; promotional and tier rules follow |