The Sprint Issues Table

Sprint Filtering Schema: Filter by Issues

 

When Filter by Issues is applied and followed by the Projects, Boards, or Sprints filters, the filtering process is the following:

Projects Issues are loaded by filtering projects.

Boards Issues are loaded by filtering boards.

Sprints Issues are loaded by filtering sprints.

All unique issues are combined into one list.

Sprints associated with the unique issues list are loaded.

The unique combinations of issues and associated sprints are being exported.

Filter by Issues Schema

 

When you apply the filter by Projects, you will get rows of unique combinations of issues and sprints.

First, the system loads project issues, including subtasks, based on the selected project. Then, the sprints associated with these issues are loaded, creating a set of unique combinations.

Filter by Project.jpg

 

In the provided example, the selected project contains 8 issues and 1 subtask. Additionally, 2 of the issues are associated with 2 different sprints respectively. Consequently, there are 11 unique combinations (rows) of issues and sprints.

Not all issues linked to your project are part of sprints. If an issue is not related to any sprint, it won’t be included in the exported table.

When you add a filter by Boards (meaning a board from another project), you create a concatenated unique list of issues filtered by both projects and boards and the sprints associated with those issues respectively.

 

In the provided example, the selected board contains 10 issues. As a result, the exported table has increased by 10 rows and now it displays 21 unique combinations (rows) of issues and sprints.

When you add the filter by Sprints (meaning a sprint from another project), you create a concatenated unique list of issues filtered by selected sprints, projects, and boards and the sprints associated with those issues respectively.

 

Sprint Filtering Schema: Filter by Parent Boards

 

When Filter by Parent Boards is applied and followed by the Projects, Boards, or Sprints filters, the filtering process is the following:

Project boards are loaded by filtering projects.

Boards are loaded by filtering boards.

All unique boards are combined into one list.

Sprints are loaded by unique parent boards list.

Sprints are loaded by filtered sprints.

All unique sprints are combined into one list.

Issues are loaded by a unique sprints list.

All unique issues are combined into one list and exported page by page with the corresponding unique combinations of issue and sprint.

 

When you apply the filter by Projects, you will get rows of unique combinations of issues and sprints.

The boards are loaded based on the selected project. Then, sprints that are associated with these boards are loaded. Finally, the issues that are associated with these sprints are loaded, creating unique combinations of issues and sprints.

When you add the filter by Boards (meaning a board from another project), you will create rows of unique combinations of issues and sprints.

The boards will be loaded based on the selected project and board filters. All boards that meet the filtering criteria are combined into a single list. Next, the sprints are loaded based on the unique boards list, followed by the loading of issues based on the unique sprints list.

When you add the filter by Sprints (meaning a sprint from another project), you create rows of unique combinations of issues and sprints. 

The boards will be loaded based on the selected project and board filters. All boards that meet the filtering criteria are combined into a single list. Next, the sprints are loaded based on the unique boards list. The sprints are also filtered and combined into a single list before loading the issues based on the unique sprints list.