Feature request template for Jira

The trouble is that requests rarely arrive structured. They land as a one-line comment from a sales call, a forwarded customer email, or a hallway “can we just add a button for this?”. Without a consistent shape, every request looks different and triage takes longer than reading the request itself. A Jira feature request template fixes that: it gives everyone outside the product team a single, predictable way to file an idea, so your team can decide quickly whether it becomes a Story, a backlog item, or a polite “not now”. Copy the template above straight into a Jira issue, or read on for what to capture, a strong-versus-weak example, how to prioritize with RICE and MoSCoW, and how to turn the structure into a reusable template with Issue Templates for Jira Cloud.

What this template captures and why

Good intake is about separating the problem from the proposed solution. People naturally describe the fix they imagined (“add a CSV import”), but the product team needs the underlying problem (“we cannot onboard 200 users one at a time”) to judge value and design the right answer. This feature request template asks for both, plus the segment the request comes from and an honest read on business value. That context is what turns a vague request into something a product manager can rank against everything else in the backlog.

It also keeps the requester accountable for the “why”. When the purpose and benefit are written down at intake, you avoid the common failure mode where a half-remembered idea sits in the backlog for months and nobody can recall what it was actually for.

Field-by-field breakdown

• Summary: a short, scannable headline for the request. Keep it to the capability, not the rationale, for example “Bulk-edit project members from the admin page”.
• Feature description: a plain-language description of the functionality being requested. One or two sentences is plenty at intake.
• Requesting user / segment: who is asking and on whose behalf. “Enterprise admins managing 200+ users” tells you far more than “a customer”.
• Problem this solves: the underlying pain, written before any solution. This is the field that protects you from building the wrong thing.
• Purpose / benefit: why the change matters and what it improves. Tie it to time saved, errors avoided, or revenue protected where you can.
• Proposed solution: the requester’s suggested approach. Useful as a signal, but explicitly framed as a proposal, not a spec.
• Business value: a simple High / Medium / Low dropdown so triage can sort quickly. Keep the scale small to avoid endless debate.
• Priority: the team’s initial ranking after a first read, distinct from the requester’s own urgency.
• Attachments: mockups, screenshots, or supporting documents that add context the text cannot.

Good versus weak examples

A weak feature request reads: “Add a CSV import.” It states a solution, gives no segment, no problem, and no value, so it will sit untriaged because nobody can judge whether it is worth doing.

A strong feature request reads: “Enterprise admins managing 200+ users currently add project members one at a time, which takes hours and causes permission mistakes. Proposed: paste a list of emails and assign roles in bulk. Business value: High, this blocks two active enterprise deals.” The difference is not length. It is that the strong version names the segment, states the problem before the fix, and quantifies why it matters. A product manager can act on the second one in seconds.

Feature request vs bug vs story

These three issue types are easy to conflate, and mixing them is what clogs a backlog. The distinction is about intent and lifecycle.

• A feature request asks for new or enhanced functionality. It is an intake artifact, raw and unscoped, and it may never get built. Its job is to capture an idea well enough that the product team can decide.
• A bug reports a defect: the software does not behave the way it is supposed to. There is an expected result and an actual result, and the gap between them is the work. See the Bug template.
• A story is a planned, scoped slice of user value that already lives in the backlog, written from the user’s point of view with acceptance criteria. See the User story template.

The relationship is sequential. A feature request, once triaged and accepted, is broken into one or more stories that get estimated and scheduled. Keeping the feature request form separate from your story format stops half-formed ideas from masquerading as committed work, and it keeps your sprint backlog clean.

Who submits a feature request, and the triage flow

Feature requests come from everywhere except, usually, the product team itself: sales relaying a deal blocker, support summarizing a recurring ticket theme, a customer success manager, or an internal engineer who hit a rough edge. A shared feature request form means all of those sources file in the same shape, so none of the context is lost in translation.

A predictable flow turns that inflow into decisions:

1. Intake. The requester fills the form. The required fields force them to name the segment and the problem, not just the fix.
2. Triage. A product owner reviews each request, deduplicates against existing ones, and confirms the problem is real and clearly stated. Requests that are actually bugs get rerouted here.
3. Prioritize. Surviving requests are scored against each other (see the frameworks below) so the backlog is ordered, not a flat pile.
4. Roadmap. The top requests are broken into stories, linked back to the original request, and scheduled. Everything else stays visible in a “later” or “not now” state so nothing is silently dropped.

The single biggest win from a template is that step two gets faster, because every request already carries the fields triage needs to make a call.

Prioritizing feature requests: RICE and MoSCoW

Once requests come in consistently, the next bottleneck is deciding which ones to build. Two lightweight frameworks cover most teams.

RICE scores each request on four factors and combines them into one comparable number:

• Reach: how many users or customers the change affects in a given period.
• Impact: how much it moves the needle for each of them, on a simple scale such as 3 for massive down to 0.25 for minimal.
• Confidence: how sure you are about your Reach and Impact estimates, as a percentage.
• Effort: the work required, usually in person-weeks.

The score is Reach times Impact times Confidence, divided by Effort. The higher the number, the better the bang for the buck. RICE shines when you have many requests and want an objective, defensible order rather than the loudest stakeholder winning.

MoSCoW is simpler and better for scoping a single release. Each request is sorted into one of four buckets:

• Must have: the release is not viable without it.
• Should have: important but not vital, has a workaround.
• Could have: nice to have if time allows, the first to be cut.
• Will not have: explicitly out of scope this time, recorded so it is not forgotten.

RICE answers “what is worth the most”, MoSCoW answers “what fits in this release”. Many teams use RICE to rank the whole backlog, then MoSCoW to draw the line for the next increment. A consistent feature request template feeds both, because every request already carries the segment, problem and business value the scoring needs.

How to use this template in Jira

With Issue Templates for Jira Cloud you do not copy and paste this structure each time. Save it once and reuse it on demand:

1. Build an intake issue with these fields in your intake project, shaped exactly like the fields above, then save it as a template. See creating issue templates for the walkthrough.
2. Add variables for the parts that change so the segment, business value, and priority are picked from dropdowns at create time rather than retyped.
3. Let requesters generate a prefilled request from the template through the issue creation screen, pre-populated and ready to submit.
4. Preserve the links between issues so each request stays connected to the Story or Epic it eventually becomes.

Frequently asked questions

What is a feature request template? A feature request template is a predefined intake form that every request follows: the summary, the requesting segment, the problem before the proposed solution, the purpose and benefit, the business value and an initial priority. It gives everyone outside the product team one predictable way to file an idea so triage is fast and consistent.

What is the difference between a feature request, a bug, and a story? A feature request asks for new or enhanced functionality and is an intake artifact. A bug reports something that is broken against expected behavior. A story is a planned, scoped slice of user value that sits in the backlog. A feature request, once triaged and accepted, is what becomes one or more stories.

How do you prioritize feature requests? Most product teams use a scoring framework. RICE ranks requests by Reach times Impact times Confidence divided by Effort, which produces a comparable number. MoSCoW sorts them into Must have, Should have, Could have and Will not have for a given release. Both turn a pile of requests into an ordered list.

How do I create a reusable feature request form in Jira? Install Issue Templates for Jira Cloud, build one issue in your intake project shaped like the fields on this page, save it as a template, then add variables for the segment, business value and priority so requesters pick from dropdowns instead of retyping.

Related templates

Pair the feature request template with the rest of your product workflow: the Bug template for defects, the User story template for the scoped work a request becomes, and the Task template for the execution underneath. Or browse the full template library for matching intake and delivery formats across software, ITSM and support work.