PRD to Backlog

The epic boundary is decided before a single story is written

One epic — User Profile & Settings — and every other decision hangs off it. Three stories sit underneath, twelve subtasks under those, and five tasks sit beside the stories rather than under any of them: technical specification, API contract, documentation, QA regression, staging deploy. That second placement is the part worth copying. Put “Define API contract” under the profile-update story and the notification story either duplicates it or silently depends on it — and a dependency nobody can see surfaces the day someone starts the second story.

The boundary test is delivery, not documentation: an epic is the smallest set of stories you would ship, announce, and support together. You would not release profile editing without validation, so both ship as one epic. Two epics called “Frontend” and “Backend” fail that test.

Note also what is absent: no date offsets. A breakdown is not a schedule — dates arrive when the epic is pulled into a sprint.

Why the error path is a story, not a ticket filed later

“System handles invalid profile data gracefully” never appears in a PRD as a heading. It lives scattered through the document as caveats: a sentence about file size limits, a table cell marking a field required. Here it is a story at !High — above the notification story at !Medium — split into subtasks separating client-side validation from server-side validation from upload errors. Break a PRD into happy-path stories only and you get a feature that demos well, then sits in QA for three sprints. The error path is where the estimate lives, and the first thing an automatic breakdown loses, because it was never a heading.

Where the automatic breakdown gets it wrong

Producing this shape takes seconds. Deciding it is right takes a person. Four failure modes recur.

• Epics that follow headings instead of delivery. A PRD is organised for a reader — background, goals, requirements, open questions. A backlog is organised for a delivery sequence. Map headings to epics and you get “Non-functional requirements”, which nobody can ship, next to “Out of scope”, which does not belong in Jira.
• Stories sized by paragraph length. “Add avatar upload with image cropping” is one line here and one line in most PRDs. It is also object storage, a cropping library, resizing and format validation — at !Medium under a !High story. Prose length says nothing about implementation complexity, but a document-shaped breakdown inherits the document's proportions.
• Acceptance criteria that encode a decision nobody made. The dangerous one, because it reads as helpful. The PRD says profile updates should feel fast; the generated criterion says “within 200ms”. Nobody chose 200ms. It enters the backlog carrying the authority of a written requirement, and six weeks later someone is optimising against a number invented to fill a field.
• Fields the source text never carried. Priorities, labels and sprint assignments come out unevenly from loosely structured text. A missing priority is easy to spot; a confidently wrong one is not.

None of this argues against generating the breakdown — it argues for the review step between generation and Jira, which is why extraction asks you to confirm you will check its output first. The reasoning is in agents don’t have hands: a model can decompose a feature in seconds, and the decomposition was never the expensive part.

Who owns which gate

• @product_owner owns the three story titles and the acceptance behind them — a story is a claim about what a person can do, so whoever is accountable for the claim writes it. No subtask carries this role: once it becomes “build the form component”, ownership moves.
• @tech_lead owns the two decisions that constrain everyone else — the technical specification and the API contract, both !High, both at epic level. Not story work, because the stories are not estimable until both exist. Starting the frontend before the contract lands is choosing to rework it.
• @designer owns the mockups gating the frontend subtasks. Two of three stories open with a design subtask; the validation story does not, because its surface is error text inside screens that already exist. Automatic breakdowns add one to every story symmetrically.
• @dev_team, @qa_team, @docs_team, @devops own execution and the exit gates. QA regression and staging verification sit at epic level because they test the epic, not one story.

Five people versus fifty

At five people most of this is over-specified. Twelve subtasks for profile settings is a board nobody needs; the epic-level tasks are a conversation and a pull request rather than tickets. Keep the epic and the three stories, drop the subtasks until something turns out harder than expected.

At fifty, the subtasks are the interface. “Build profile update API endpoint” and “Implement profile form frontend components” are two teams and a contract between them — which is why the OpenAPI spec is its own !High task. What stops being optional: that contract, the design-before-frontend ordering, and QA regression as a named gate.