Skip to content

JIRA & Release Management
What How releases are created, tracked end to end, aligned with Git, and closed.
Owner Project Manager (release lifecycle), with the whole team keeping tracker hygiene.
Triggers Every sprint, feature cycle, or planned delivery.

Summary

A dedicated JIRA Release is the single source of truth for everything in an iteration. Every sprint or delivery gets one, and all work items (epics, stories, tasks, sub-tasks, test plans, build and deployment tickets) live inside it, including any bugs QA finds. Git branch names carry the exact release version, so code, tracking, and deployments are always traceable to one another. A release is closed the same day it ships and is then locked; new work always means a new release with a new version.

Full detail

Mandatory JIRA Release per delivery

A JIRA Release MUST be created for every sprint, feature cycle, or planned delivery. It is the single source of truth for that iteration and includes all associated work items:

  • Epics, user stories, tasks, sub-tasks
  • Release test plans
  • Build and deployment tickets

This gives complete visibility and traceability for everything planned.

QA bugs go in the same release

When QA finds a bug during testing, it is added to the same JIRA Release the sprint or feature belongs to. This keeps a complete picture of: what was intended and planned, what was developed, what issues QA found, and what was actually delivered. That completeness is what makes retrospectives, audits, and Escaped Defects Analysis possible.

Tracker hygiene

  • All work is tracked. The PM (or designated person) creates stories for all requirements.
  • Each story has sub-tasks for the relevant roles (Backend, Frontend, DevOps, QA).
  • Estimates: story-level in story points, task-level as original estimates in hours.
  • Every team member logs work hours daily at the sub-task level before end of day.
  • Stories carry clear descriptions, acceptance criteria, and appropriate labels.
  • The board reflects real-time, accurate status.

Aligning Git branches with JIRA releases

Every release and hotfix branch name MUST include the exact JIRA Release version. This makes traceability effortless in both directions: from a branch to its release, and from a running version back to its code.

release/v1.3.0   ->  JIRA Release v1.3.0  ->  app version 1.3.0
hotfix/v1.3.1    ->  JIRA Release v1.3.1  ->  app version 1.3.1

flowchart LR
    A[JIRA Release v1.3.0] --- B[Git release/v1.3.0]
    B --- C[Tag v1.3.0]
    C --- D[App version 1.3.0]
    A --- E[All epics, stories, tasks, bugs, test plans, build tickets]

Release closure

Once a build is finalized, tested, and released to users:

  • The JIRA Release MUST be closed the same day.
  • This marks it released and locked, preventing further modification.
  • No new stories, tasks, or bugs may be added to a closed release.

New work needs a new release

If new work is required after a release is closed:

  • A new JIRA Release MUST be created with a new version number, matching a new Git release branch and app version.
  • All new work goes into this new release.

This prevents two branches sharing a version but holding different code, versioning conflicts, environment inconsistencies, regressions from mismatched branches, and lost work from untracked parallel changes.

Required practices, at a glance

You must: create a JIRA Release per sprint or feature; include all dev and QA tickets in it; add QA bugs to the same release; name Git branches with the release version; close the release immediately after deployment; create a new release for any new work after closure.

You must not: add issues to a closed release; reuse a version number for future development; maintain two branches with identical versions but different code.

Example

The sprint gets JIRA Release v1.4.0. Every story, sub-task, the release test plan, and Build Ticket BUILD-58 live inside it, and the two bugs QA finds during testing are added to the same v1.4.0 release rather than a new one. The Git branch is release/v1.4.0 and the production tag is v1.4.0, so the number lines up across JIRA, Git, and the app version. The afternoon it ships, the Project Manager closes v1.4.0, which locks it. A new request the next week opens a fresh JIRA Release v1.5.0 rather than reopening the closed one.