Using Boards

While you can display linked issues in the card layout of Active Sprints and the Backlog view on a board, you cannot see how each card fits into the full hierarchy.

This limits visibility into the complete dependency tree and may lead to work being scheduled out of sequence, which can create bottlenecks later.

You can create a report from the Manage Pivot Reports page or from within a Board, referencing up to two closed sprints.

Afterwards, you can update the report source to include up to five closed sprints, as shown in the screenshot above, by following the steps in the related article.

Closed sprints cannot be displayed on a board. In contrast, you can create a report specifically for those sprints, to perform a retrospective of what what delivered.

In the screenshot below, a completed sprint appears with a green label and strikethrough text, while an active sprint is shown with a blue label and no strikethrough.

In the example, the Remaining Time for completed issues in the closed sprint is 7 hours. If the original estimates were unchanged, these hours were likely overestimated.

Even after accounting for these 7 hours, more than six days of work remain for issues planned but not completed during the sprint. This indicates that the sprint was not successfully delivered as scheduled.

You cannot create a report that references custom sprints directly from the board. However, you can update the report source to include them, as described in the related article.

The screenshot below shows a custom sprint added to the report source.

For example, a report created for a single sprint, as shown below, lets you monitor the remaining time for that sprint alongside issue status, assignee, priority, and issue type. If an assignee’s remaining work exceeds the sprint’s remaining time, those deliverables are at risk of not being completed.

In the screenshot, Emily Lake has over two weeks’ worth of deliverables remaining. If the sprint lasts only two weeks, these tasks are unlikely to be finished.

When a sprint closes and an issue is not set to Done, it is moved to the next sprint or returned to the Backlog. To track how often this happens from the board, you must enable the Sprint field in the card layout of the Active Sprints and Backlog view.

Alternatively, you can use JQL in the Issue Navigator to manually identify issues assigned to a sprint more than once, as shown in the screenshot.

As this number increases for incomplete issues, the risk of delay grows. You can then compare Time Spent against the Original Estimate to decide whether the issue should be reassigned, re-evaluated, or descoped.

This article explains how to display a report in sync with a board using a shortcut, as shown in the screenshot above.

Why should you display a shortcut?

When a report uses the same source as a board (such as a JQL filter or projcet), it reflects changes made to that source, including status updates, sprint closures, or other board configuration changes.

By adding a shortcut, as shown in the screenshot above, you can access the report directly from the board. If you update the board while the report is open, reload the report to ensure it reflects the latest changes.

How can you display a shortcut?

To add a shortcut to the project sidebar:

1. Under Project shortcuts, click + Add shortcut.

2. Enter the web address (URL) and a label for the shortcut. The label can be different from the report name. Afterwards, click Add to save the shortcut.

Whether you use a single sprint for the entire development team, separate sprints per project (as shown in the screenshot below), or one sprint per release, you can review their contents simultaneously in a report.

A Jira admin can enable or disable parallel sprints by going to Administration (gear icon) > Applications > Jira Software configuration > Parallel Sprints.

By default, when you create a report using the actions menu in the Board:

1. Report name – Matches the board’s name where the actions menu is used. Until saved, the name remains a hyperlink to the board.

2. Description – Shows which sprint work items are included.

   • For Active Sprint, Future Sprint, or Backlog issues, the description reflects the option selected. For example, the screenshot above shows a report created from the SSP board for Active Sprint issues.

   • For Custom issues, the description displays “Board Report” when the report is created using options from the Pivot Report Options pop-up.

No. Team-managed projects exist only in Jira Cloud. You cannot create a report for them on Jira Data Center or Server, based on the current constraints set by Atlassian for Jira.

For details on locating the project type or migrating to another type, see the related article.

Yes. You can prevent users from creating reports from a board by removing their access to the app entirely.

The screenshot above shows a report built from a board to display Backlog issues. No issues appear because items with a To Do status are not mapped to any column on the board.

As a result, these issues do not appear on the board and are not included in the report.

Yes. The number of issues in the report source directly affects Jira’s API performance, which determines the report’s loading time—not Pivot Report itself.

• To speed up loading, reduce the number of referenced issues or those added through extensions (parent or child issues).

• Also, specify which projects or boards Jira should search. A narrower search scope means fewer issues for Jira to process, resulting in faster results. Atlassian’s documentation offers additional JQL optimization tips.

In Jira Data Center, alerts help identify slow and complex JQL queries, including those with many custom fields. Atlassian provides detailed thresholds for these alerts in a separate article.

Yes. Reports can display more issues than a board or the Issue Navigator. However, loading time increases as the issue count grows.

Working with high issue count in Cloud

Atlassian notes that searches have no issue limit, but display limits apply:

• Boards and backlogs show up to 5,000 issues.

• The Issue Navigator shows only the first 1,000 issues.

A report can help you work around certain Jira limits, though it may increase loading time. For example, a board may fail to load if it reaches the maximum issue limit.

In contrast, you can create a report based on the board or its underlying source filter. However, this report may take longer to load compared to one linked to a board that has not reached the maximum limit.

Working with high issue count in Data Center

The display limit for the Issue Navigator can be increased using a documented workaround. A report does not require this workaround, although very large reports may load more slowly.

Similarly to prior example, a report linked to a board or its underlying source filter may take longer to load if the workaround was applied to increase the limit.