Insights (Reports)
Topics
- 1 Reports for Versions
- 1.1 Version Burnup
- 1.1.1 Report output
- 1.1.2 Projected release date
- 1.1.3 Export to CSV
- 1.2 Version Trends
- 1.2.1 Report configuration
- 1.2.2 Report content
- 1.3 Release Frequency Report
- 1.3.1 Report configuration
- 1.3.2 Report content
- 1.1 Version Burnup
- 2 Reports for Packages
- 3 Other Reports
- 4 More Reports?
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.
Report configuration
User can choose any version in the board using version selector:
Available units are:
Issue Count
Story Points
Original time estimate
User can adjust report output via custom JQL queries:
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:
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] + 50% of [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.
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.
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.
Report configuration
Following configuration parameters are available:
Version selector. Choose a version for which the report will be built.
Data aggregation interval. The user can choose an interval for which the data will be aggregated in the report. Available options:
Day
Week
Month
Unit. Supported units are:
Issue count
Story points
Original time estimate
JQL. The report content could be adjusted via custom JQL function.
Done items switcher. Turn on/off done items trend (meaning: version velocity)
Scope change switcher. Turn on/off scope change trend.
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.
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:
Period of the data aggregation.
Scope change trend line.
Velocity trend line.
Scope change and velocity for the current period are outlined with a dotted line.
In trends report, we calculate the number of items added or removed from the release (Grey Line) on a daily/weekly/monthly basis and track the trend of completed versus reopened items (Blue 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, we count it as newly added scope, increasing the Grey 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 Grey and Blue lines.
The same approach applies to removed items, which decrease the values for the Blue and Grey 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 Blue line.
Reopening decreases the Blue line.
The Grey 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 Grey and Blue lines.
Changing the estimate for TODO or IN PROGRESS category items only affects the Grey 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:
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
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:
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:
Cumulative package progress. The chart shows the cumulative scope and progress for all the versions in the package on a daily base
Individual versions progress. Separate charts for each version in the package.
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:
Cumulative trends for all version in the package.
Separate trends for individual version in the package.
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:
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
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.