How to Write Jira Epics with AI (with Cagan's Four Risks)

Why most Jira epics are just repackaged feature lists

Ask most teams why an epic is sequenced where it is, and the honest answer is usually "it was next on the roadmap" or "engineering had capacity." Neither is wrong exactly, but neither is a reason grounded in what could actually kill the initiative. An epic built as a container for related stories, with no explicit statement of what it's meant to prove or de-risk, is a filing structure wearing a strategic costume.

Marty Cagan's framing is useful here specifically because it's uncomfortable: every product bet carries value risk (will customers use it), usability risk (can they figure out how), feasibility risk (can engineering actually build it in scope), and business viability risk (does it work for the business — legally, financially, operationally). Most teams are only fluent in worrying about one of these — usually usability, because it's the most visible — while feasibility and business viability quietly sink more projects.

An epic that doesn't name the risk it's meant to retire isn't a delivery plan — it's a to-do list with a nicer name.

The pattern repeats across teams that would never admit to skipping risk assessment: they'll happily discuss usability in a design review and feasibility in a sprint planning meeting, but rarely in the same conversation, against the same epic, before any code is written. By the time the gap surfaces — a legal review that blocks launch, an integration that turns out to need three more sprints than estimated — it's discovered in production planning instead of in the ten minutes it would have taken to ask the question up front.

Step 0 — What you need before writing an epic

Don't start from a blank epic template. You need a validated strategic direction — the output of a sparred product strategy or at minimum a clear problem statement — and ideally a PRD that's already specced the what. Epics answer "in what order, and what's the risk at each step," which only makes sense once "what are we building" is settled.

Step 1 — Ground the agent in the initiative and what's already known

Same discipline as every other artifact: give the agent your context before asking for epics. Keep in your workspace:

• context/product.md — what exists today, what's already been attempted, known technical constraints
• The initiative or PRD this epic set is delivering, so epics are scoped against a real spec, not a guess
• context/company.md — team capacity and any hard constraints (compliance, partner dependencies) that shape business viability risk

Without this, an agent will happily assess "feasibility" against no information, which produces confident-sounding risk labels that mean nothing — the same trap covered in why context beats prompts generally.

Step 2 — Ask for risk-mapped epics, not a checklist

Here's a starting prompt. The instruction that matters most is forcing an explicit risk label per epic — without it you get a tidy list that still hides what actually matters:

Read context/product.md, context/company.md and the PRD/initiative
I'm about to paste, first.

Break this PRD into delivery epics. For each epic:
1. Name the primary risk it retires: value, usability, feasibility,
   or business viability (Cagan's four). An epic can touch more than
   one, but name the primary reason it exists.
2. State what evidence would tell us the risk was real vs. imagined
   — what would we observe if this epic's risk actually materialized?
3. Flag epics where feasibility risk is uncertain and you don't have
   enough technical context to judge — list the specific question
   to bring to engineering, don't guess at an answer.

Then propose a sequence: which epic should go first because it
retires the highest-uncertainty risk, not because it's the easiest
to build. Argue for the sequence, don't just list it.

PRD/initiative: [paste it]

Rule 3 matters because feasibility risk is exactly where an ungrounded agent is most likely to bluff — it will assess "buildability" against no real engineering input if you let it, and a confident wrong answer here is worse than an honest "ask engineering." The agent's job is to surface the right question, not manufacture a fake answer to it.

What good output looks like: not "Epic 3: build the export feature," but something with a stated reason to exist — "Epic 2: bulk export to CSV. Primary risk: feasibility — we don't know if the reporting service can handle exports above 50k rows without a timeout, and nobody's tested it. Evidence that would confirm the risk: a load test against production-scale data before committing to the UI work. Sequence this before Epic 1 (the export UI), because if the service can't handle the volume, the UI work is wasted regardless of how good it looks." That's a sentence a skeptical engineering lead would actually nod along to, not push back on in the next standup.

Step 3 — Sequence by risk, not by convenience

The instinctive sequence is whatever's easiest to build first, because early momentum feels good. The risk-driven sequence is often less comfortable: build the piece most likely to prove the whole bet wrong, first, while the cost of being wrong is still small. Push the agent on this directly — "which epic, if it failed, would tell us the fastest that this initiative isn't going to work?" — and put that one earlier than instinct suggests. A wrong epic discovered in week two is a pivot. The same epic discovered in week ten, after three other epics were built on top of it, is a much more expensive conversation.

This is also where it's worth being honest with yourself about incentives: the easy epic is easy to defend in a status update ("shipped on time!"), while the risky epic might produce a result nobody wants to report — "we built it and confirmed the bet doesn't work." That second outcome is a success for the company and feels like a failure to whoever's name is on the epic. Sequencing by risk means occasionally choosing the update that's harder to deliver in a standup, because it's the one that actually protects the roadmap from being built on a false premise.

Step 4 — From epic to sprint-ready stories

Once epics are sequenced, each one still needs to become work a team can actually pick up — sliced into Jira-ready user stories with testable acceptance criteria, then pushed to the tracker. Keeping this in the same grounded session means the stories inherit the epic's stated risk and evidence question instead of a fresh engineer re-deriving "why are we building this particular slice first" from the ticket title alone — the reasoning travels with the work, not just the requirements.

Common mistakes to avoid

• Sequencing by ease, not by risk. Building the comfortable epic first just delays discovering the epic that was actually going to be a problem.
• Treating every epic as equally risky. If nothing is named as the primary risk, you haven't actually assessed risk — you've made a list.
• Letting the agent guess at feasibility. A confident wrong answer about buildability is worse than an honest "ask engineering this specific question."
• Skipping business viability entirely. It's the least visible of the four risks and the one most likely to surface as a launch blocker nobody flagged.
• Writing epics before the PRD is settled. Epics answer sequencing and risk for a spec that already exists — they're not a substitute for deciding what you're building.

FAQ