Is there a way to remove Sprints created on other Boards from my Board's Reports on Jira Cloud?

[Ramsi Hawkins]

Hi, I'm trying to figure out if there's a good way to only include Sprints created from a given Board in the Reports generated from that Board? I believe there's a way to do this in server, but I can't figure it out in Cloud.

The biggest problem I'm trying to solve is the situation where a ticket moves from one Space to another and into another team's active sprint without first removing it from the Sprint on the old Board. When this happens and the Sprints close there's no way of removing the closed sprints from the ticket. This makes teams then have to do manual velocity calculations because there's random 0 story point sprints in their velocity graph.

It seems like if we know a Sprint's origin board it wouldn't be hard to having a setting that only shows reports from that origin board.

I'm open to data work arounds to solve my problem.

[Sebastian Quesada Ocampo]

Hi @Ramsi Hawkins 

Unfortunately, in Jira Cloud there is no native way to exclude sprints created on other boards from a board’s reports. Reports (such as Velocity) are generated based on all sprints that contain issues matching the board filter, regardless of which board originally created the sprint.

Jira Cloud does not provide a UI setting to filter reports by a sprint’s origin board.

That said, via the Jira Agile REST API you can identify the board a sprint belongs to (or at least where it was created). When querying a sprint by ID, the response includes the originBoardId:

• GET /rest/agile/1.0/sprint/{sprintId}
• The response includes originBoardId, which points to the board that created the sprint

With this, you could programmatically filter sprints and exclude those whose originBoardId doesn’t match the current board. However, this information cannot be used in a simple JQL query. You would need to build something more complex, such as:

External reporting or custom velocity calculations

Scripts or marketplace apps (ScriptRunner) that consume the API and post-process the data

Out of the box, Jira Cloud reports cannot leverage originBoardId, so this remains a data-level workaround rather than a native solution.

[Ramsi Hawkins]

That's pretty much what I thought, but I appreciate an informed second opinion.

I'm curious from a data side if you've got any suggestions on how to clean the data manually.

The best way I can think of is to go in, reopen the offending Sprints, move the tickets in question out of the Sprint, then close the Sprint again, but I think this generally requires sprint permissions across Spaces so isn't really a feasible self-service option for users.

The only other approach I've thought of requires going in and grabbing the sprint IDs of all of the Sprints each issue is legitimately part of and then go in and individually go through the bulk change process with each issue and manually set the Sprint list to be correct. This feels like an even sketchier solve though.