Stories, Not Braindumps

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:

• Stories get written like a note to self: commit hashes, file paths, middleware names, "see thread in Slack," no user in sight.
• Work items get broken into lots of little Tasks, and those Tasks are hung directly off Epics, skipping the Story layer entirely.
• Acceptance criteria are tangled with implementation notes, so nobody can tell what "done" means without reading the code.

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.¹ That is not the problem. The problem is what each level is for:

• Epic. A body of work, usually spanning multiple sprints. Framed as an outcome, not a feature list. "Customers can pay with SEPA direct debit." "Admins can self-serve team membership."
• Story. A slice of user-visible value that fits in one sprint. This is where the who, what, why lives. The unit product and design can reason about.
• Task. Work with no direct user-facing value. Library upgrades, CI chores, an infra migration, deleting dead code. Real work, worth tracking, but nobody will ask "what did this deliver?"
• Subtask. Engineering detail inside a Story or Task. A place for implementation steps, not for the overall work item.

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.

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:

1. The title is the implementation. "Migrate auth middleware to v2." No user, no outcome. Compare: "Users stay signed in across tab reloads." Same work. One is a story. The other is a task the engineer wrote for themselves.
2. Acceptance criteria mixed with technical notes. "AC: 1) Sessions survive reload. 2) Refactor 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:²

It looks like a formality. It is not. It forces you to answer three questions you will otherwise skip:

1. Who is this for? If you cannot name a role, you are probably writing a task.
2. What are they trying to do? In their words, not yours.
3. Why does it matter? This is the hardest clause and the one most worth keeping. Everything else can be relaxed. The "so that" is the part that survives a refactor of the template.

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).³ 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?".⁴ Two decades later it is still one of the most compact sanity checks available.

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.

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.

1. They are not hours. They estimate size, which bundles complexity, uncertainty, and effort into one relative number. A 3 is roughly three times the size of a 1. It is not three hours, three days, or three anything fixed.
2. Fibonacci, not linear. The canonical justification is Weber's Law: humans cannot reliably distinguish quantities that differ by only a small ratio.⁵ A 4-point story and a 5-point story are noise. A 3 and an 8 are genuinely different. The gaps are on purpose.
3. The value is the conversation, not the number. If three engineers estimate independently and come out at 2, 2, 13, stop. Do not average. The 13 saw something the others did not. That is the whole point of pointing.
4. 13 is a signal, not an estimate. When the room agrees on 13, the correct next move is almost always "we do not understand this yet, let's split it or spike it."

A small taxonomy that tends to hold up across teams:

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.

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.⁶ 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:

• Is it a story or a task? A story describes a change in system behavior from the perspective of a user. "Refactor the payment module" and "upgrade the ORM" are not stories, and no splitting pattern will turn them into ones. Splitting patterns apply to stories; tasks get a different treatment.
• Does it pass INVEST except for Small? If the only failing letter is S, splitting is the right tool. If it also fails on Valuable (no one benefits) or Testable (no observable outcome), the problem is framing, not size. Fix the story before you split it.
• Is it actually too big? A useful sanity ratio: a sprint should comfortably hold roughly 6 to 10 stories for the whole team. If a single story would eat a third of the sprint, it wants splitting. If the team finishes 12 stories per sprint and this one is a 5-pointer, the urge to split may be premature.

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:

• Prefer roughly equal-sized slices. A 5-5-5 split gives product three shippable options. A 12-1-1 split gives them one real story and two rounding errors.
• Prefer splits where the first slice teaches you something. If slice one confirms a usage pattern, exposes a data problem, or proves an integration works, slices two and three become much cheaper to estimate and build. The point of slicing is not just smaller; it is smaller and faster to learn from.

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.⁷ 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.

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:

1. Spike. Is there a genuine unknown hiding in this story? If yes, extract the research as its own timeboxed ticket and replan the rest.
2. Paths. Does the story describe more than one path through the system? If yes, pull the happy path out as its own slice.
3. Interface. Is the UI interaction doing most of the work? If yes, ship a plain version now and style it up later.
4. Data. Are there different data shapes involved? If yes, start with the simplest one.
5. Rules. Are there multiple business rules baked in? If yes, ship one rule at a time.

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:

And here is the same work, written as a story:

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?)

• It has an actor, an outcome, and a reason (the three Connextra questions).
• It has at least one testable acceptance criterion.
• Dependencies are linked, not assumed.
• Nobody at the refinement meeting walks out saying "I still do not really know what this is."
• It fits in a sprint. If it does not, it gets split before it enters one.

Definition of Done (can this story leave the sprint?)

• All acceptance criteria are verified by someone who is not the implementer.
• Tests exist at the appropriate level and are passing.
• The change is merged, deployed to the target environment, and observable.
• Documentation / release notes / internal announcements are updated where they need to be.
• The ticket itself is closed with a short comment on what actually shipped, especially if scope changed.

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.

1. Story and Task are different on purpose. Story has a user and a value. Task is plumbing. Put Tasks under Epics only for plumbing work; reach for Story whenever a human benefits.
2. Write for the reader who is not you. The who, the what, and the why belong in the ticket, in plain language. Commit hashes and file paths do not.
3. INVEST is a cheap sanity check. Run down the six letters before you pull a story into a sprint. "Testable" is the one most teams fail.
4. Points measure size, not time. Fibonacci is not a gimmick; the gaps are there because your brain cannot distinguish a 4 from a 5. The number matters less than the conversation that produced it.
5. Split vertically, not horizontally. Find the core behavior and peel variations off the outside: workflow steps, CRUD operations, business rules, data shapes, input methods. Every slice should ship on its own and teach the team something that makes the next slice cheaper.

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.

• Atlassian: Epics, Stories, Themes, and Initiatives

  The canonical reference for how Jira's hierarchy is intended to work, including the peer relationship between Story and Task.

• Bill Wake: INVEST in Good Stories, and SMART Tasks

  The 2003 article that introduced the INVEST acronym. Short, still the best summary.

• Ron Jeffries: Card, Conversation, Confirmation

  The 3 C's of user stories from 2001. Two pages, still essential.

• Agile Alliance: User Story Template

  Origin and usage of the Connextra 'As a, I want, so that' template.

• Mike Cohn: Why the Fibonacci Sequence Works Well for Estimating

  The Weber's Law justification for Fibonacci story points, from the person who popularized them.

• Humanizing Work: The Guide to Splitting User Stories

  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.

• Mike Cohn: What Is SPIDR?

  A compact five-letter mnemonic (Spikes, Paths, Interfaces, Data, Rules) that covers the most common subset of the Humanizing Work patterns.

• Dan North: Introducing BDD

  Origin of the Given / When / Then format for acceptance criteria.

• Atlassian Team Playbook: User Stories

  A current, practical facilitation guide for running a story-writing session as a team.