Real-world Rovo Use Case: Sprint Capacity vs Logged Effort Analysis

[Febin Philipose]

Hi Atlassian Community,

I’ve been experimenting with Rovo for a practical delivery management use case and wanted to share the experience to see if others have explored something similar.

As a Delivery Manager, one recurring challenge is understanding whether sprint capacity aligns with actual effort spent — especially when accounting for planned leave and expected utilisation.

I tested a Rovo workflow to compare:

• Planned sprint capacity (3-week sprint, adjusted for leave)
• Time logged in Jira tickets
• Expected utilisation threshold (e.g., 80% logged effort)

What impressed me was that Rovo could actually reason through the logic and generate a utilisation analysis in Confluence — which felt like a strong step toward smarter delivery insights.

However, I hit a few practical limitations:

• Processing can take 15–30 minutes for capacity vs logged effort analysis
• Re-prompting often triggers re-validation from scratch
• Jira time logs currently need to be manually exported to CSV and uploaded

This made me think about a potential opportunity for Rovo Agents.

Could a custom Rovo Agent connected directly to Jira time-tracking automate utilisation reporting and continuously generate sprint/weekly insights without manual intervention?

I’m curious:

1. Has anyone attempted a similar Rovo use case?

2. Is there a better way to approach this using existing Atlassian capabilities?

3. Could this be something better solved through automation rather than prompting?

Would genuinely love to learn from how others are approaching this.

Kind regards,
Febin

Contact: https://www.linkedin.com/in/febin-philipose/

[Alexander Nilsson]

Hello Febin,

good use case to share, and the limits you ran into are exactly the ones that show up when chat-driven Rovo gets pushed into recurring reporting. The fix is to flip the architecture: stop prompting from Chat, invoke the agent from Jira Automation instead.

Atlassian supports this directly. You can wire a "Use Rovo agent" action into any Jira Automation rule, including a Scheduled trigger that fires at the end of every sprint. From the agent side, you can also attach a trigger to the agent in Studio so it activates on the event you want. The full pattern, including the follow-up action that consumes {{agentResponse}}, is documented here:

https://support.atlassian.com/rovo/docs/agents-in-automations/

In your shape it would look like: scheduled trigger every 3 weeks at sprint end, branch by JQL over the sprint, "Use Rovo agent" action prompting your custom agent with the JQL context, then a text-output action such as "Add comment to page" against a target Confluence page using {{agentResponse}}. The agent itself only needs the relevant Jira project as a knowledge source, so no CSV export is required, since it reads work items and worklogs through that scope at run time.

One thing worth separating out: most of what you described is deterministic math (planned capacity adjusted for leave, summed logged time, percentage against an 80% threshold). That part does not actually need an LLM. Jira Automation already exposes {{triggerIssue.worklog.timeSpentSeconds.sum}} and supports arithmetic in smart-value expressions, so you can compute utilization in the rule itself and only pass the rolled-up numbers plus context to the agent for the narrative section. That keeps the Rovo call short and deterministic, avoids the re-validation loop you noticed when re-prompting, and consumes fewer credits. The reference for that smart value:

https://support.atlassian.com/automation/kb/how-to-get-total-time-logged-into-an-issue-using-automation-for-jira/

For larger sprints, be aware that agents invoked from automation are not built to reason across very large JQL result sets. The practical pattern is to have Automation aggregate per assignee or per epic first, then feed the agent the rolled-up table rather than a long flat list, which is what was driving the 15 to 30 minute waits.

I am looking forward to your feedback :)

Greetings,

Alex

[Sowjanya Mupparaju]

@Alexander Nilsson Right approach. I was about to suggest the same to call the Rovo agent inside the Jira automation.