Rovo/AI Limitations: Why we can’t automate "Next Sprint" Board views (and how to fix it)

[Yuval Cohen]

Paste directly from ROVO:

Hi everyone,

I’ve been working with Atlassian Rovo to automate team workflows, and we hit a significant "wall" when trying to create a dynamic Next Sprint Board. I want to share the technical feedback on why this is currently impossible for both users and AI agents, and how the Jira Product team could resolve it.

The Problem

We tried to create a "Twin Board" of an existing Scrum board that would automatically increment to show the Next Sprint (using sprint in futureSprints()). While the JQL is simple, the Jira UI and API architecture make the result unusable for two reasons:

1. The "Active Sprint" UI Lock

In Jira Scrum boards, the "Board" view (columns) is hard-coded to only render tickets from the Active sprint.

• The AI Conflict: Even if Rovo creates a board with the correct futureSprints() filter, the board appears "Empty" to the user because the tickets are hidden in the Backlog tab.

• Requirement: We need a way to allow Scrum boards to "Preview" or "Render" the column view for the next planned sprint without needing to close the current one.

2. API Inability to "Clone" Board Configurations

There is currently no API endpoint to CLONE a board’s full configuration (Column mappings, Quick Filters, Card Colors, Swimlanes).

• The AI Conflict: When I ask Rovo to "Make a board just like Board X," it has to try and rebuild every setting one by one. This is error-prone and often results in a board that feels "broken" or "basic" compared to the original.

• Requirement: A POST /board/{id}/copy endpoint that allows an AI agent (or user) to duplicate the UI logic of a board while only changing the underlying JQL filter.

Why this matters for Rovo & AI

For Rovo to be a true "teammate," it needs to be able to set up environments that match a team's existing standards. Currently, Jira’s rigid sprint-state logic and the lack of configuration-cloning in the API prevent AI from performing even "simple" setup tasks.

Has anyone else found a workaround for visualizing future sprints in a column view, or is there a roadmap item to open up Board Configurations via API?

[Jordan Wilkinson]

It's a very dangerous idea to overlap two scrum boards with the same data. Sprints end up being created in the wrong place, then it gets out of hand and bad things happen to reports and integrations.

Instead, use a kanban board to view the data for the future sprints of you just really want a column view. 

What I don't quite understand is what you expect to see in columns if the work has not started. Since the columns map to statuses, and work in the backlog likely has no status change (work started), then everything will mostly be in column 1, which isn't helpful. In a similar example, I've seen some teams use a kanban board for the backlog grooming activities with dedicated "pre-sprint" review statuses. That makes sense, but then those stories were actually hidden from the scrum board until they were fully groomed and ready for work, so they would not already have been planned into future sprints. 

What's the real goal?