Can Rovo access Sprint Burndowns as a data source?

Question

Hi everyone,

I’m building a Sprint Review Assistant in Rovo to pull together sprint outcomes, completed work and carryover into a Confluence page. Naturally, one useful feature has led to me wanting another 😅

Has anyone managed to get an agent to access the underlying data behind Jira’s sprint burndown or Sprint Report?

I’d love to include what we committed to at the start, work added or removed during the sprint, and changes to estimates. That would give the review much better context around what changed along the way and what we actually delivered.

The important bit for me is using verified historical data, rather than asking the agent to piece together the past from how tickets look today. The team can then add the “why”.

Has anyone found a reliable workaround here?

Arkadiusz Wroblewski · Answer

Hello @Jamie Wilkins

A feature request already exists for native Rovo access to Jira reports, including burndown and sprint reports: ROVO-961. Jira also provides a bulk changelog API, which may be more efficient than querying each issue separately. Just be sure to include any issues removed from the sprint when reconstructing the original commitment.

Best,

Arek 🤠🧙‍♂️

Ciro · Answer

Hi,

Not as a ready-made source, as far as I know: Rovo doesn't read the Sprint Report or burndown data, and the endpoint the Sprint Report uses isn't part of Jira's public REST API. But the history behind it is there, so two ways to give your agent verified data:

* Rebuild past sprints from the changelog. Each work item's history records every change to the Sprint field and to the estimate field, with timestamps (GET /rest/api/3/issue/{issueIdOrKey}/changelog). Compare those with the sprint's start and end dates from the Agile API (GET /rest/agile/1.0/sprint/{sprintId}) and you get committed at start, added, removed and re-estimated. To let the agent call it, wrap it in a Forge Rovo action (a GET action).
* Snapshot future sprints with Automation. The Sprint created, started, or completed trigger can run when the sprint starts and branch over its work items to stamp them, e.g. tick a Committed at start field and copy the estimate into an Estimate at start field. The agent then compares those fields with what's done, using plain JQL.

Option 2 is a lot less work; option 1 is the only one that covers sprints already closed.