Dedicated Target Release Date Field in Jira Cloud Releases

XMLWordPrintable

    • Type: Suggestion
    • Resolution: Unresolved
    • None
    • Component/s: Project - Releases
    • None

      Summary
      Currently, Jira Cloud uses the Release Date field both as the target (planned) release date and the actual release date. When a version is released and the release button is pressed, the system overwrites the intended target date with the actual release date. This results in a permanent loss of planning data and prevents accurate tracking of schedule performance.

      To better support project managers, programme managers, and engineering teams, we request the addition of a dedicated, permanent “Target Release Date” field (and optionally a “Target Start Date” field) within the release model.

      Problem Statement
      The dual purpose of the existing Release Date field creates the following issues:

      • Once a version is released, the target release date is overwritten, removing historical planning data.
      • It becomes impossible to measure schedule performance, slippage, early delivery, or adherence to target milestones.
      • Reporting, forecasting, and governance activities are negatively impacted due to the loss of planned timelines.
      • Teams lack a reliable way to compare planned vs actual release dates.

      Requested Enhancement
      Add the following fields to the Release Model:
      1. Target Release Date (new field)

      • Represents the planned release date.
      • Should remain immutable after the version is released.
      • Enables tracking of:
        schedule variance
        percentage progress towards planned release
        whether delivery occurred early, on time, or late
        overall reliability of release forecasting

      2. Target Start Date (optional, but valuable)

      • Represents the planned date when work on the version should begin.
      • Allows tracking of whether execution started on time or was delayed.

      Retain existing fields:
      3. Start Date

      • Indicates when work on the version actually began.

      4. Release Date (existing behaviour retained)

      • Should represent the actual release date only.

      Benefits

      • Restores and preserves critical planning data.
      • Enables accurate reporting on:
        schedule variance
        delivery performance over time
        programme-level release forecasting
      • Supports large-scale delivery organisations with governance or audit requirements.
      • Provides more transparency for stakeholders and leadership teams.
      • Eliminates accidental loss of planned timeline information when pressing “Release”.

      I was unable to locate an exist request like this, if one already exist then please link this to that one.

              Assignee:
              Unassigned
              Reporter:
              jhussain
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: