---
title: "Insights (Reports)"
canonical: "https://help.releasemanagement.app/space/RMC/478314497/Insights%20(Reports)"
format: markdown
---
> Macro (include)

# Topics

> Macro (toc)

# Reports for Versions

## Version Burnup

> ℹ️ Not available for **JQL Versions**. Supported for all other Version Types.

> 📝 Due too technical limitations for **Epics **we can build it only based on existing scope whether it was part of the Epic from the beginning or added later. We won't account removed items.

Version burnup report helps you track version scope changes and development progress over time. It also allows highlighting expected or unexpected scope changes and version progress trend towards expected release date. 

![image](media://ca74033f-52f3-41dd-8caa-e1d05f5b975a)

 Report configuration

User can choose any version in the board using version selector:

![image](media://4f8f8c47-8e2b-4c62-a036-b7e17ede67d6)

Available units are:

- Issue Count
- Story Points
- Original time estimate

User can adjust report output via custom JQL queries:

![image](media://58ede4c5-f04a-444e-9e5a-735d9439708b)

> ℹ️ **Few popular Use Cases:**
> ℹ️ 
> ℹ️ - New features and technical improvements burnup: *issueType in (Epic, Story, Task) *
> ℹ️ - Exclude sub-tasks: *issueType in standardIssueTypes()*
> ℹ️ - Burnup for assignee: *assignee was <user_name>*

Also, user can choose from additional drawing options:

1. **Draw version from the start date.** If the option is enabled, the report is drawn from the version start date. Otherwise, from the date when the first item was added into the version.

> ⚠️ The option is not available if version start date is empty.

### Report output

1. Total scope of the version is calculated on a daily base in selected units

2. “Done” scope of the version

3. Guideline. Shows ideal burnup rate in order to complete version in time. 

> ⚠️ Guideline is only available if Start and Release dates are specified.

4. Start date. Indicates version start date

5. Release date. Indicates version release date

### Projected release date

> 📝 If **start date is defined **and **at least 30% of release scope is completed **we will calculated projected release date and outline the guideline on the chart.

How we calculate the % of the work completed?

> **[% of the work completed] = % of **( [all issues in all versions with status category **Done**] + <span style="color: #bf2600">**50% of **</span>[all issues in all versions with status category **In Progress**] ) / [all issues in all versions]

If **[% of the work completed] **is >30% and <100% we will calculate Projected Release Date as following:

> **[projected release date] = **[start date] + **[projected days in release]**

where

> **[projected days in release] = **(** **[today] - [start date] ) / **[% of the work completed]**

*In essence, we evaluate today’s progress and, assuming the current velocity remains constant, estimate the time needed to reach full completion.*

Because the calculation involves a degree of approximation, we typically include a 10–15% uncertainty buffer on both sides of the projected release date.

![image-20251124-154824.png](media://3702fdd3-9724-44b1-9fc5-2be283b710da)

### Export to CSV

Total scope and amount of “Done” items could be exported in CSV format in case you want to build a more sophisticated view with XLS or Google Spreadsheets.

![image](media://63bef4de-c091-421f-97ab-d235ec32ec7e)

The resulted document structure is:

|  |
| --- |
| ```
"Date","Total","Completed"
"2019/10/28","87","16"
``` |

## Version Trends

> ℹ️ Not available for **JQL Versions**. Supported for all other Version Types.

> 📝 Due too technical limitations for **Epics **we can build it only based on existing scope whether it was part of the Epic from the beginning or added later. We won't account removed items.

This report helps to outline “scope change” and  “done items“ velocity trends of the version. 

![image](media://04a8c06d-ed95-4667-b24d-7f380e4da740)

### Report configuration

Following configuration parameters are available:

![image](media://0a12c4fb-4c32-491d-89cf-4791b7e75b9b)

1. **Version selector.** Choose a version for which the report will be built.
2. **Data aggregation interval**. The user can choose an interval for which the data will be aggregated in the report. Available options:
  1. Day
  2. Week
  3. Month
3. **Unit**. Supported units are:
  1. Issue count
  2. Story points
  3. Original time estimate
4. **JQL**. The report content could be adjusted via custom JQL function.
5. **Done items switcher.** Turn on/off done items trend (meaning: version velocity)
6. **Scope change switcher.** Turn on/off scope change trend.
7. Draw from start date. **If the option is enabled, the report is drawn from the version start date. Otherwise, from the date when the first item was added into the version. **
  The option is not available if version start date is empty.

![image](media://93b5251a-023f-4f30-88ff-4a65615e5e19)

> ℹ️ **Few popular Use Cases:**
> ℹ️ 
> ℹ️ - Bugs trend report: *issueType=Bug *(Units: Issue count)
> ℹ️ - Version velocity: *issueType in standardIssueTypes() *(Units: Any)
> ℹ️ - Business value delivered trend: *issueType in (Task, Story, Epic) *(Units: Issue count or Story Points)
> ℹ️ - Performance per person: *assignee was <user_name> *(Units: Any)

### Report content

The report has the following content:

1. Period of the data aggregation.
2. <span style="color: #97a0af">**Scope change trend line.**</span>
3. <span style="color: #4c9aff">**Velocity trend line.**</span>
4. *Scope change and velocity for the current period are outlined with a dotted line.*

![image](media://a80e8c29-9f5d-47f7-9a4b-cadb381bb77b)

In trends report, we calculate the number of items *added *or *removed *from the release (<span style="color: #97a0af">**Grey **</span>Line) on a daily/weekly/monthly basis and track the trend of completed versus reopened items (<span style="color: #4c9aff">**Blue **</span>Line).

The calculation includes the following events:

- **Work item entry or exit from the release:**
  - If an item enters the release in the [TODO] or [In Progress]  [status categories](https://support.atlassian.com/jira-cloud-administration/docs/what-is-a-workflow-status/), we count it as newly added scope, increasing the <span style="color: #97a0af">**Grey **</span>Line.
  - If an item is added to the release with a status in the [Done] category, we count it as both newly added and completed scope, increasing both the <span style="color: #97a0af">**Grey **</span>and <span style="color: #4c9aff">**Blue **</span>lines.
  - The same approach applies to removed items, which decrease the values for the <span style="color: #4c9aff">**Blue **</span>and <span style="color: #97a0af">**Grey **</span>lines, potentially making them negative.
- **Completion or reopening** of an item (moving from [TODO] or [In Progress] categories to the [Done] category):
  - Completion increases the <span style="color: #4c9aff">**Blue **</span>line.
  - Reopening decreases the <span style="color: #4c9aff">**Blue **</span>line.
  - The <span style="color: #97a0af">**Grey **</span>line remains the same.
- **Re-estimating**, if the chart is based on estimates rather than issue count:
  - Changing the estimate for the [Done] category items changes both the <span style="color: #97a0af">**Grey **</span>and <span style="color: #4c9aff">**Blue **</span>lines.
  - Changing the estimate for [TODO] or [In Progress] category items only affects the <span style="color: #97a0af">**Grey **</span>line.

## Release Frequency Report

[ADVANCED EDITION] 

The Release Frequency Report provides valuable insights into the frequency of releases based on their release date or status changes. It helps teams analyze release frequency trends over time, assess delivery cadence.

**Use Cases:**

- Track the frequency of releases across time periods, with a focus on making more frequent releases
- Gain visibility into how often releases transition through key statuses and spot bottlenecks by seeing a large number of releases in certain statuses.

This report supports data-driven decisions by making release patterns transparent and measurable.

### Report configuration

Following configuration parameters are available:

![image-20250708-081630.png](media://b9a63f88-22ae-4fc6-a641-4bef2b7af6bd)

- **Selected Period: **What period is included
  - This Week, Month, Quarter, Year
  - or Custom Period

- **Outlook Display: **Data to show
  - Show archived versions (some releases version could be already archived)
  - Show unreleased versions (usually only released included)
  - Include Trendline

- **Date Source Selection: **Choose how releases are counted based on:
  - Release Date
  - Status Change Date to one or more selected statuses (e.g., "Released")

- **Flexible Grouping Options: **Break down the report by:
  - Project
  - Project Category
  - Release Status (e.g., Released, Unreleased, or from the board columns)
- **Time-Based Grouping: **Visualize the number of releases grouped by time intervals:
  - Weekly, Monthly, Quarterly, Yearly

### Report content

Here’s an example of report output

![image-20250708-081821.png](media://59376552-6a39-4c00-8210-0d7e75225723)

Putting mouse over bar/stacked-bar you will see an annotation elaborating on the data you see.

You can also click on any of the bars (or elements of stacked bars) to se to know the details about releases included into aggregation:

![image-20250708-081854.png](media://26db3988-e66e-4394-8222-f8ed3f6749ff)

# Reports for Packages

## Package Burnup

Package burnup chart is similar version burnup though provides some additional sophisticated features for Release Managers to use. It consists of two main parts:

1. Cumulative package progress. The chart shows the cumulative scope and progress for all the versions in the package on a daily base
2. Individual versions progress. Separate charts for each version in the package.

![image](media://df930346-f6e8-4864-aaf9-b762671091f6)

Report logic is the same comparing to versions burnup.

> ✅ If you click on “Draw from Start Date“ both cumulative and individual versions burn ups will be adjusted and depicted from package start date. Thus you can see what specific versions contributed to scope / progress change on daily basis.

## Package Trends

Package trends report is similar to version trends report. It consists of two main parts:

1. Cumulative trends for all version in the package.
2. Separate trends for individual version in the package.

![image](media://265215cb-e5d2-40b4-a2ba-4853e7bec08d)

## Package Status Report

Package status report helps users to understand the overall status of the package and all its included versions.

The following information about the package and its versions is available:

- Status
- Issues progress
- Start date
- Release date

User can select any package available in the Release Board using the Package selector:

![image](media://7564b4bb-7c28-4ae7-8766-0e514adc585f)

# Other Reports

## Scope Change Report

> ℹ️ Available for fixVersions only, not the Virtual versions.

Scope change report helps users to identify the issues that caused affect on the scope of a version or package.

The report has two sections:

- Added issues - issues which were added to the target version or package during a specified period
- Removed issues - issues which were removed from the target version or package during a specified period

Report parameters include:

- Target version or package
- Predefined date periods with the option to specify custom start and end dates
- Filter by issue types

![image](media://68591976-9804-455b-a5df-14f4694f2f6e)

The following issues details are displayed:

- Issue type, key, summary
- Status
- Priority
- Currently assigned versions from "fixVersions" field
- Story points
- Original, remaining and logged work (hours)

The total number of issues in each section is displayed together with the Sum of Story Points and Time Tracking fields.

# More Reports?

## Suggest your report

We are open to your feedback! If you have an idea or need any other report, please let us know using the simple feedback form:

- Report name - required field
- Report description - required field
- Your email - this is optional if you want to let us know to contact you about your suggestion.

> Macro (include)