Jira Epic vs Story vs Custom Issue Type for Feature Requests
Don't create a dedicated issue type by default. Jira's hierarchy has three fixed tiers, Epic at the top, Story/Task/Bug in the middle, Subtask at the bottom, and a custom issue type lands in that middle tier alongside Story, not in some new level between Epic and Story. If what you actually want is "a bigger bucket for asks that span months," a custom type doesn't get you there. Use a label on the existing Epic or Story instead, and reserve a custom type for the one thing it's genuinely good for, giving intake a different workflow and different required fields than delivery work gets.
That's the honest answer, and it comes straight from how Jira's hierarchy is built, not from a style preference. The question "should this be an Epic, a Story, or its own type" sounds like three points on one scale. It isn't. Epic vs Story is a size decision. Custom-type-or-not is a workflow decision. Conflating them is what sends people down the Jira Community rabbit hole of asking for a "Feature" level that doesn't exist.
The three tiers Jira ships with
Every Jira Software space ships with the same three-tier structure. Epic sits at the parent level; Story, Task, and Bug share a standard level underneath it; Subtask sits below that. Atlassian's own documentation on work types confirms Premium and Enterprise plans can create additional hierarchy levels beyond the default three, for portfolio-level work like initiatives. Those added levels stack above Epic, not between Epic and Story, as an Atlassian Community regular spells out in the thread below. There is no native way to insert a level between Epic and Story.
That matters because Epic, in Atlassian's own words, is meant to be "a large user story that can be broken down into a number of smaller stories", scoped by size, not by who's asking or how many accounts want it. A feature request that three customers asked for and a feature request that thirty customers asked for are the same size, from Jira's perspective, until you estimate the work. The hierarchy has nothing to say about demand.
Why "just add a custom issue type" doesn't solve the size problem
This is the exact confusion playing out in two long-running Atlassian Community threads. In one thread, a team wants Epic (release-level) → Feature (multi-sprint) → Story (single sprint), and gets told plainly by a Community regular that "Advanced Roadmaps create layers above Epic, not between it and Issue." The fixes people land on are third-party: the Structure app, or BigPicture, both of which impose a custom hierarchy on top of Jira's native one, at real license cost. In a second, older thread, asking for the same Initiative → Epic → Feature → Story shape, the accepted answer comes from Eugene Sokhransky of ALM Works, who makes the Structure app the thread points to elsewhere, and his fix is to rename the existing Epic field to "Feature" via a config parameter rather than create anything new. Worth weighing that his employer sells the paid alternative to that fix. Several people in that thread compare it unfavorably to Azure DevOps, which ships a native mid-level out of the box.
Read those two threads back to back and the pattern is obvious. Everyone who tries to solve "how big is this ask" by adding an issue type ends up either buying an app or renaming a field, because a same-tier custom type can't do a different-tier job. Whatever you name it, a type you create yourself sits in the standard tier next to Story, Task, and Bug. It inherits the same hierarchy position, just a different label on the box.
Where a custom type earns its keep is workflow, not size. If intake needs a review step, "Needs Triage" → "Approved" → "In Backlog," before anything becomes committed work, and delivery issues shouldn't carry those statuses, a distinct type with its own workflow and required fields (a mandatory "Requesting account" field, say) is a legitimate reason to create one. Atlassian does exactly this itself: its own documentation lists a native New feature work type shipping by default on Jira Service Management projects, alongside Incident, Problem, Change, and Service Request, because customer-facing intake in a portal is a different workflow than engineering delivery. That's a precedent for "feature requests deserve their own type," but it's a precedent for separating how a request enters the system from how it gets sized once it's in, which is a narrower claim than most teams reach for.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionNaomi Bricker's team picks a lane
Corrigan Depot sells warehouse inventory software to mid-size distributors, on a company-managed Jira project with the standard Epic, Story, Task, and Bug set. Naomi Bricker leads platform engineering there, and for two years her team filed customer-driven asks as Stories tagged customer-ask, mixed in with the rest of the engineering backlog.
By early this year, that stopped working for one specific reason. A Story is supposed to be one unit of committed work, and half of what customers asked for wasn't that. A rep would ask for "better filtering on the receiving dashboard," and three months later that had turned into six separate Stories across two sprints, none of them linked, because nobody had decided up front whether the original ask was Epic-sized or Story-sized.
The breaking point came up in a planning retro. Naomi asked the room outright: they kept filing these as Stories and then discovering they were Epics once scoped, so why not just make a "Feature Request" issue type and settle it up front? Raj, the team's senior engineer, pushed back: a new type wouldn't change anything, because the request would still need to become an Epic or a Story once someone sized it. Naming it earlier didn't make the sizing happen any sooner.
Raj's objection held up, and it's the same gap the two Community threads ran into. Corrigan's fix wasn't a custom issue type; it was a rule. Every customer-driven ask starts as a Story with the label customer-ask, and stays a Story until scoping says otherwise, at which point it gets promoted to an Epic and the original Story becomes its first child. The label carries the "this came from a customer" signal across that promotion; the issue type carries the size, and only the size.
The point one person tracking labels can't scale past
That rule holds up as long as one person is deciding, by hand, which asks are the same ask. It stops holding up once volume grows past what one person tracking labels in their head can dedupe. Corrigan hit that wall around forty live customer-ask Stories: the same filtering request had been filed three separate times by three different reps, under three different labels (customer-ask, filtering, and nothing at all, because the third rep didn't know the convention), and nobody noticed until a fourth rep asked about it in Slack and someone remembered filing it twice already.
A label is free text with autocomplete, not a managed list, so drift like that is the expected outcome at scale, not a fluke. It also doesn't carry who asked. Once a Story gets promoted into an Epic and split three ways, the original requester's name lives in a comment somewhere, if anyone wrote it down, and reconstructing which accounts wanted the eventual feature means reading every linked issue's history by hand. Our companion guide on who actually asked for a Jira epic or story goes deeper on that specific gap, since Jira's Reporter field tracks who filed the ticket, not who asked for it, and those diverge fast once more than one person can file issues.
This is the point where we build Modem. Modem doesn't ask you to pick a taxonomy up front. It reads the request wherever it happens, a call, a Slack thread, a support ticket, and clusters the different phrasings of the same ask into one topic, counting how many accounts are behind it before anyone opens Jira at all. When a topic is ready to become real work, Modem's Jira integration creates or links the issue in whatever type your project already uses, Story, Epic, or a custom type if you have one, and keeps every account and quote attached to that issue as a context graph, not a label that can be typed three different ways. The size decision still happens in Jira, where it belongs; the "who asked, and how many" question stops depending on someone remembering to tag it right. (We build Modem, so weigh that recommendation accordingly. Our guide on turning customer feedback into Jira tickets compares the manual approach against a few other tools that touch this same gap.)
If your team is still small enough that one person can hold the dedupe list in their head, Naomi's rule, customer asks start as Stories with a label, promote to Epics once scoped, is genuinely sufficient, and adding a custom issue type on top of it would only add workflow you don't need yet.
Write the rule down, skip the new type
Pick the label, one label, not three variants of it, write the one-line promotion rule (label stays on Stories; it travels to the Epic when one gets created), and post it where whoever files tickets will see it. Skip the custom issue type unless you can name a workflow step or a required field that Story doesn't already give you. If you can't name one, the type isn't solving anything the label wasn't already handling.
