How to Create a Release in Jira and Track Progress Through the Release Lifecycle

[#1]

Release management or sprint management?

Most teams run on sprints, and sprint management in Jira feels intuitive.

But the value your team delivers to users isn't tied to sprints. It's tied to releases. A sprint is just a step on the road to that value. You can hit every sprint goal and still miss the release. The sprint asks “is the work complete?” The release asks “is it shipped?” When teams don't distinguish between the two, sprint metrics look great while the release quietly drifts.

It's crucial for a team to have a clear picture of both processes and how they sync up. When you're ushering a version to production, you really need to track all release-related work in real time, spot risks early, and communicate ship dates with confidence.

This guide is about closing that gap: how to set up release management in Jira and which tools help you actually see the process of delivering value to users.

How to create a release in Jira

To start using release management in Jira, just create a Release and add issues to it via the Fix Version field. In Jira, “release” and “version” mean the same thing. Treat them as full synonyms.

Here's how to set up a Release in Jira:

1. Add Releases to your project navigation. If you don't see a Releases tab in your project's top navigation, click the + button in the navigation bar. In the Views menu that appears, find Releases and click Add to navigation. This makes the Releases tab visible alongside your Board, Backlog, Calendar and other views.

2. Open the Releases tab. Click Releases in the top navigation. You'll see the Release Hub. If no versions exist yet, it'll say “No matching versions.”

3. Create a Release. Click the button in the top-right corner.

4. Fill in the details and save. A dialog appears, where you fill in the name, the dates, and assign a driver.

📌Pro tip: Use a consistent naming convention. Otherwise you'll lose traceability very fast. If you manage multiple applications, prefix your version names with the app name like MOB-v2.1.1 or API-v1.0-backend. When you're looking at a JQL result that pulls issues from five projects, the prefix tells you instantly which release belongs to which product.

5. Add issues to the release. Once your version exists, you need to connect issues to it. You can do this:

• From the release page itself: open the version in the Release Hub, click “Add work items,” and search for the issues you want to include.
• From the issue itself: open any issue, scroll to the details panel, and find the field called Fix Version. Select your version from the dropdown.

📌Fix Version vs. Affects Version: Jira issue has two version-related fields. Fix Version tells you which release this issue ships in. Affects Version tracks which version a bug was found in. Most teams only use Fix Version. If you’re not using Affects Version, that’s fine. Don’t add complexity you don’t need.

The visibility gap

There's a gap in native Jira. The release date sits in one view, the tasks sit in another, and nothing connects them to tell if the team is going to make it or not. That gap becomes more painful as teams and releases grow.

Visualizing the release lifecycle with Planyway

Why your progress bar is lying to you

When looking at the progress bar of any active version, you’ll see, say, 70% done, 20% in progress, and 10% to do. But will the remaining work actually be finished before the delivery date? A release can be 90% complete and still late if the last 10% includes a task that isn’t assigned to anyone, or one that’s blocked by an external dependency.

Progress bars measure completion, not timing. And what you really need is a real-time view where you can watch tasks progress toward the release date. If something isn't going to make it, you want to see it immediately. And even better: share that view with stakeholders via a link, so they can see whether the release is on track without asking you.

The spatial release progress bar

In Planyway, a release isn't a progress bar tucked into a sidebar. When you enable the releases lane in View Settings, your Fix Versions appear on the same timeline where your tasks live. You can see the gap between where a task bar ends and where the release lane sits. If a task bar extends past the release date, the conflict is immediately visible.

Cross-project release visualization

Jira versions are project-scoped. If you have a “Mobile” project and a “Desktop” project, each has its own set of releases. There's no native way to see them side by side in the standard version of Jira. In Jira Premium, it is possible to create a cross-project release, but the grouping exists only inside the Plan view. It doesn't appear in your Release Hub or anywhere else in Jira.

In Planyway, releases from all projects appear on the same timeline. Combined with the workload view, you can also check whether the people or teams assigned to release-critical tasks have the capacity to finish on time. The red indicator makes it visible when someone is overloaded

Jira release management workflow

After you've created a release and assigned issues to it, it’s time to make sure it actually ships on time, with the right scope, and without last-minute surprises.

Standardize your version lifecycle

First advice to follow: archive anything older than two releases. So anyone who needs historical data can always filter for it in JQL.” Jira versions have three statuses: Unreleased, Released, and Archived. Looks simple, but many teams never archive old versions, and over time the Releases tab becomes a graveyard of “Version 2.4 new beta” and “Pre-launch test 3” entries that confuse everyone on the team.

Manage scope changes explicitly

When a task isn't going to make the cut, move it to the next version. Change the Fix Version so the task stays tied to a concrete release and nothing falls through the cracks.

When to cut the scope

At some point during every release, you'll face the question: do we push the date, or do we ship without this? In most cases, cutting scope is the healthier choice. A release that ships on time with 90% of the planned features earns more trust than one that's late with 100%.” The scope freeze practice below helps you make this call early, not the night before launch.

A scope freeze rule

This is a habit that keeps releases predictable. Set a date after which no new issues can be added to the version. Like 5 or 7 days before the release. Then enforce it with a JQL filter:

fixVersion = “v2.1.0” AND created >= “-5d”

If this query returns results after the freeze date, someone broke the rule. Use this filter in a dashboard gadget or a Slack notification to catch violations early.

Definition of Done

Agree on your Definition of Done and make it precise. Until your team has a shared understanding of what “Done” actually means, you can't trust any release metric. If “Done” means “code complete but untested,” your progress bar is lying to you. A task in Done should mean ready to ship: code reviewed, tested, and deployable.

Version-level best practices

A few things that experienced release managers do that aren’t obvious from the documentation:

• Don’t create versions too far in advance. Planning is great, but having too many unreleased versions clutters the Fix Version dropdown and causes confusion. Two or three upcoming versions is a balanced choice.
• Use the release description field. This helps anyone looking at the Release Hub understand the intent of the release. Keep it short and clear: “Customer service improvements” or “Q2 Desktop features.”
• Review the release scope weekly. Open the Release Hub, check the progress breakdown, and ask: is anything unassigned? Is anything marked "In Progress" but hasn't moved in days? Is someone working on three release-critical tasks at once? A five-minute weekly check catches problems that a launch-day audit can’t fix.
• Keep your dev process and release process loosely coupled. A scrum team should be able to close sprints without waiting for a release window, and the release process should pull from completed work without disrupting the current sprint. When the two processes are tightly linked, a delay in one cascades into the other.
• Separate “team done” from “shipped.” If your workflow only marks tasks as Done when they hit production, finished tasks pile up on the board for weeks, dragging down velocity and cluttering the sprint. A practical fix for that is to add a “Release Ready” status mapped to the Done category.

Reporting and analysis: looking beyond the Release Hub

The release burndown chart

Jira’s built-in release burndown chart shows how much work is left in a specific version and how fast your team is getting through it. It’s genuinely useful for single-project releases with stable scope, but it has limitations: it only covers one project at a time, it doesn’t show whether tasks are actually scheduled before the release date, it can’t incorporate team capacity or workload.

One thing worth watching in the burndown: when the actual line diverges sharply from the ideal line, resist the temptation to wait and hope. That divergence almost always gets worse, not better. The moment you see it, investigate which issues are stalled, who’s blocked, and whether the remaining scope is realistic.

Three ways to build an executive-level release view

1. JQL dashboard with gadgets. First create a JQL-filter for your release (fixVersion = “v2.1.0”), then add a Two-dimensional filter statistics gadget. You’ll get issue counts broken down by status and component in a table view. It’s free and can be quite useful, but it won’t show you the timeline.
2. Cross-project releases inside Jira Plans. Plans lets you visualize your cross-project releases on a timeline. It’s a solid tool for planning and reporting, but requires Premium.
3. Planyway multi-project timeline. It covers all the connected projects in one view, shows tasks scheduled against the release date on the same timeline, and includes team workload. It works on any Jira plan, including free version. For teams that need a visual release dashboard without the enterprise price tag, this is the most practical path.

What to include in a release report

A good release report should answer three important questions:

• What are the current blockers, and who owns them?
• How has the scope changed since the freeze date (issues added or removed)?
• What’s the completion percentage by component?

The component-level breakdown is especially important because aggregate numbers often hide the problem. A release that’s 85% complete overall might be 100% done on the frontend and 40% done on the API layer.

📌Pro tip: For recurring releases, keep a lightweight template: scope changes, blockers, per-component status, and a one-line confidence assessment (”green, yellow or red”). It takes five minutes to fill out and another five minutes to go through it to keep a pulse on the release.