Short answer: Jira generates basic release notes from Fix Version assignments — go to the Releases page, click on a version, click 'Release notes'. The output is a list of issues by type. It's fine internally but unreadable to customers. The version customers actually read is a curated version: 3-5 highlights, plain language, written by a human. Three settings most teams miss: Fix Version hygiene, issue-type configuration, and a release-notes-only filter.
Jira generates release notes from Fix Version assignment. To get started, go to your project’s Releases page. Click on a version. Click the “Release notes” option. Then choose a format. The issues arise on the list of issues by category – feature, bug, task. The version generated automatically.
Why this matters: automatically generated Jira release notes may be suitable for internal communications, but they aren’t suitable for customers. The external shipment format contains chosen excerpts three to five highlights, plain English, human phrasing in writing. Many teams wonder why no one reads the auto-generated version they send to customers. Atlassian's own guide to release management makes the same split between internal versioning and customer-facing announcements.
In this comprehensive guide, we explore how to create release notes in Jira by using three tricks to set auto-generated release notes quality, ever version gets read by customers and finally, how to bridge the auto-generated and the curated. To whom this is Useful - PMs, eng leads, and release managers who manage the release communication from Jira. Teams migrating from Jira often start by running the Jira importer for Pivotal Tracker and immediately hit the same release-notes question on the new tracker.
How to generate release notes in Jira
The process, step by step.
- Open the Releases page for your project (sidebar → Releases).
- Click the version you're releasing.
- Click the "..." menu and select "Release notes" (or click "Release" if you're shipping for the first time).
- Choose a style:
- HTML — formatted for embedding.
- Text — plain text for plain documents.
- Configurable format — custom template (more on this below).
- Optionally filter by issue type (e.g., exclude internal tasks).
- Click Create or Generate.
The output consists of a list of issues that have been resolved in the version. These issues are arranged according to issue type or resolution type. More or less.
## v3.2.0 — Released 2026-05-15
### New Features
- LITE-432: Bulk import for users
- LITE-451: Slack integration
### Bug Fixes
- LITE-440: Fix navigation bug on Safari
- LITE-446: Correct date display in DST regions
### Tasks
- LITE-433: Upgrade to Node 22
This is the unprocessed result. It's acceptable for internal communications; it is not acceptable for customer-facing release notes. A similar shape comes out of release markers in Tracker, which most teams pair with a hand-written summary before sending anything externally.
The three settings that determine quality
1. Fix Version hygiene.
The assignment of Fix Versions determines the quality of release notes. The Fix Version data of most Jira projects are inconsistent.
- Issues resolved before a release without a Fix Version assigned.
- Issues with multiple Fix Versions assigned.
- Issues with the wrong Fix Version (assigned to a version other than the one they actually shipped in).
Solution: Ensure Fix Version is assigned when marking incident as resolved. Include a JQL filter (fixed in the last 30 days and Fix Version is empty) and check it weekly. Fill the voids.
2. Issue-type configuration.
The release notes automatically generated group issues by type. If your issue-type list is “Story / Task / Bug / Sub-task / Epic” with no other structure, your release notes will simply be “Stories, Tasks, Bugs, Sub-tasks, Epics”. This doesn’t really help customers identify value.
It is better to use both patterns.
- A custom field for "Customer-facing impact" — values like "New feature", "Improvement", "Bug fix", "Internal only". Use this field for release notes grouping instead of issue type.
- Per-issue release-notes text — a custom field where the author writes one customer-facing sentence per issue. The auto-generated notes then read like prose, not a JIRA dump.
3. The release-notes-only filter.
Most fixed issues aren’t worth mentioning in release notes. Engineering does know about refactors, dependency upgrades, test improvement, infra work; customers don’t care.
Incorporate a personal field "In the release notes requested” (boolean), and adapt the generator for the release notes to filter by means of this. By default, no. The PM marks it as important if the issue truly matters to customers.
We have the opinion that… Teams often create their release notes by taking “everything that’s in the version”, resulting in notes with 40 items. Customers skim through these 40 items since they can’t find anything useful or relevant. A focused subset of five to ten items gets read. The same instinct to over-pack each release is the one we wrote about in why software teams cram features into each release instead of cutting back.
The version customers actually read
Jira version generated automatically is the internal release notes, verbose, ticket-IDs visible, every change is logged. Helpful in maintaining engineering records and updating stakeholders.
The release notes that go to the customers eh?
| Aspect | Internal release notes | Customer release notes |
|---|---|---|
| Length | 30–100 items | 3–8 items |
| Format | Ticket IDs + titles | Plain prose, no IDs |
| Detail | Every change listed | Highlights only |
| Audience | Engineering, support, internal stakeholders | End users |
| Voice | Engineering shorthand | Customer-facing copy |
| Generated by | Jira auto-generation | Human writes, optionally seeded from Jira |
This is what a good release note looks like
## What's new in v3.2 — May 15, 2026
**Bulk import for users.** You can now upload a CSV of users to add them
to your team in one go. Up to 500 users per upload. Find it under Settings →
Team.
**Slack integration.** Connect your Slack workspace to get notified when
issues are assigned to you or change state. Setup takes about a minute under
Settings → Integrations.
**Bug fixes.** We fixed a navigation glitch on Safari and corrected a date
display issue for customers in daylight-saving regions. Thanks to the
customers who reported these.
Keep it simple, write three to five plain language items, no ticket IDs, has to be written by a human or edited by a human with AI assistance. Your clients will read this.
The PM convert the output he gets from Jira - a list of things auto-generated by the engineering team - into customer-facing content. He uses it as a checklist to pick out all the things worth mentioning in customer-facing content. Then he rewrites it in easy, plain language. Use 5 minutes’ worth of work per release. The raw material is the auto-generated version; the customer version is the product.
Automating without losing the human touch
Two automation models yield success.
Pattern 1: Per-issue release-notes field.
When the issue has customer impact, the engineer writes a one line description that’s customer facing on the issue. The field forms part of the standard story template. When it’s time to release, the PM string these together, edits for fluency, and ship.
There are many advantages when talking about planned economic activity. Discipline is required because some writers use engineering lingo instead of customer-oriented content.
Pattern 2: Release-notes draft generation.
Employ a script or AI tool to draft customer-facing notes using data from a Jira issue, then edit by human. The text that appears in writing isn’t the end product.
Advantages include speed and data utilization. The drafts given by AI are too generic and editing is necessary.
Creating release notes is an efficient use for AI, useful for the boilerplate part of the work: formatting, structuring, etc. The Voice segment doesn’t provide much utility for the narrative (what to include, how to describe, which tone). Utilize it for the draft; don't export the draft unedited. If your build pipeline already maps tickets to deploys — the workflow described in deliver Tracker stories from Capistrano — the draft input is essentially free.
The focus of LiteTracker is grounded in this difference, as the internal issue data is informative in nature whereas the release-facing content is curated. The two are structurally separate, so you don't accidentally ship your internal language to them.
The most common release notes failure
After a sufficient number of releases, one pattern marks: the team generates the release notes automatically from jira and posts them to customer portal verbatim and not read by customers.
Symptoms.
- Release notes should have ticket IDs (LITE-432).
- Notes have engineering short hand e.g. refactor session token handling.
- Release notes feature more than 30 items, none curated.
- Support is repeatedly asked questions about features in the notes because these are not visible.
The solution is devised by a human issue that is normally accomplished by the PM and sometimes a tech writer. As the auto-generated notes are read, a human picks the 3–5 things worth mentioning and rewrites them in a customer language. The inputs are provided by the auto-generation and the rewrite gives the outputs.
Another error is skipping release notes entirely. The thought process suggests we deliver continuously without versions. This this process is easy to do this. Even if the shipping is continuous, periodic summarization is useful to customers. A monthly digest fills the gap: not “v3.2.0 release notes” but “what we shipped in May”. The traceability problem this introduces — knowing which build a fix landed in — is the one covered in where is my story deployed? and you want that answered before you skip notes.
When release notes aren't worth the time
The truthful instances.
- Pre-PMF startup with manual customer outreach. If you're personally talking to every customer, release notes are duplicate communication. Skip until the customer count outgrows personal contact.
- Internal-only software. Internal users get the auto-generated version; no curation needed.
- Continuous-deployment products with feature flags. Each feature flag rollout is the release; the customer-facing release notes are the feature announcements, not a Jira summary.
- Products with strong in-app discovery (tours, badges, popups). The product itself communicates new features. The release notes become a reference, not a primary channel.
Yes, prepare release notes that are customer-facing. Utilize Jira as the origin, rephrase into plain language, ship the curated version.
The math behind smaller releases
The benefits of smaller stories are staggering. The cycle times drop from day to hour. Teams reach users up to 14x faster. The same logic applies for releases too. We can make smaller, frequent releases (weekly, fortnightly) that produce shorter release notes that customers read. Quarterly mega-releases produce 80-item notes that nobody finishes. Martin Fowler made the same point years ago in FrequencyReducesDifficulty, and DORA's State of DevOps research shows the elite teams ship many times per day rather than batching. The small-batch approach to validating your business model is the same idea applied to the release-notes problem.
We ship to our customers frequently, deploying releases which contain customer-facing notes once a month. The Fix Versions (aka internal versioning) can remain granular for engineering tracking; customer communication is the monthly digest.
Frequently asked
How do I generate release notes in Jira?
To view release notes, open the Releases page and click on the version followed by Release notes from the dropdown. Select either HTML, text, or configurable format. The output is a list of resolved issues categorized by issue style. This is the internal version; the customer-facing version isn’t AI-edited.
What's the difference between auto-generated and customer release notes?
Every resolved issue gets a technical note, complete with ticket ID. The release notes should be a curated selection of 3-5 points in plain language with no ticket IDs. The version that’s auto-generated is the raw material, and the one for the customer is the product.
How do I customise the release notes template in Jira?
Use the config format option in JIRA, it allows template editing by Velocity templates. For most teams, this is overkill a custom field for ‘release notes text’ per issue plus external write-up delivers better results than fighting with Jira templates.
Should release notes include ticket IDs?
Yes, internal release notes are required by engineering and support. Customer-facing release notes? No! Ticket IDs are noise for customers, and a signal you didn’t curate.
How often should I send release notes?
Align Release Cycles Products with continuous-deployment use aggregate on a monthly basis. Release products every quarter. Notes sent out less than once every three months feel old. Ones sent out more than once a week feel like noise.
Can I automate customer-facing release notes?
Partially. AI tools are able to draft notes to clients from data in Jira. This means that the editing step is crucial as there is a tendency for the AI drafts to be generic and miss the voice and emphasis of the decisions that humans make. Rely on AI for rough drafts than the final.
What if my team doesn't use Jira Fix Versions?
If that is the case, you cannot use Jira's release notes generation. You can either start using Fix Versions (the preferred path), or generate release notes from somewhere else (a sprint label, a GitHub release, a custom filter).
Should bug fixes go in customer release notes?
The sole ones that matter for customers. “Fixed a regression introduced by our last release” is a yes; “refactored the auth middleware” is a no. The priority is whether the customer would care about the difference, not whether engineering did.
Still stuck
Jira’s release notes play a pivotal role within the overall trajectory of a release. The internal version (that’s generated automatically) is raw material; the customer version is a curated version in plain English. Omitting the rewrite step, most teams then wonder why customers do not read the notes.
If having a first-class customer-facing-impact field for the tracker you use is essential for you and you want the release notes generation to respect that by default, then that is the kind of property that LiteTracker is built around. No Limits on Users When you are a small team without a customer portal, drop the formal release notes entirely and use a monthly product email instead customers prefer that anyway.
Automatically Generate for Engineering, Curate for Customers or Devices in Either Case