Rovo Agents and Automation in Jira: Building a Sprint & Release Manager, Step by Step
A walkthrough of a real custom Rovo Agent built for a two-week release cadence — what worked, what didn't, and where the split between automation and agent actually lands.
Every two weeks, the same loop starts again. New sprint, new release version, new set of issues to test, new release notes to draft. At TitanApps, one release goes out per sprint, which means this cycle runs 26 times a year — and every step of it used to be manual.
When Rovo Agents landed in Jira, our Product Lead Oleksandra Sokol built a Sprint & Release Manager Agent to carry most of that load. Some of it worked cleanly on the first try. Some of it needed workarounds. One part turned out to belong in plain Jira Automation, not in an agent at all.
This is a walkthrough of what she built, how she built it, and where the split between agent-work and automation-work actually lands. If you're just getting into Rovo Agents in Jira, this is also a broader read: Rovo Agents: How To Use and Transform Your Jira Workflows by the Atlassian team.
Key takeaways
- Rovo Agents in Jira handle analytical work like summaries, release notes, and triage better than they handle structural work like creating sprints or assigning issues to versions.
- The fastest way to start is to describe your goal in Studio with Rovo Chat and let it scaffold the automation rules for you.
- A dedicated Rovo Agent with detailed instructions produces sharper output than repeating raw prompts inside every automation rule.
- Rovo Agents can be triggered from automation rules, by transitioning to workflow status, while editing/working with issues, or by being assigned to a Jira work item like a teammate.
What Rovo is
Atlassian Rovo is Atlassian's AI layer for Jira, Confluence, and the wider Atlassian ecosystem. It shows up in four surfaces:
- Rovo Chat is a conversational assistant that pulls context from your connected tools. Ask it for status updates, page summaries, or a rundown of your open Jira work items.
- Rovo Search is enterprise search across Jira, Confluence, Google Drive, Slack, Bitbucket, and other knowledge sources. Ask in plain language, get results across products.
- Rovo Agents are customisable AI teammates that follow instructions and take actions on your behalf.
- Rovo Studio is the workspace where you build agents, custom apps, and automations.
Rovo pulls context from the Teamwork Graph, Atlassian's cross-product knowledge graph that connects work items, pages, people, and relationships. That's what lets an agent working on a Jira work item also read the linked Confluence PRD or the related release notes.
What Rovo Agents actually do
A Rovo Agent is a customisable AI worker with four building blocks: instructions (the system prompt), skills (predefined actions like "create page" or "comment on work item"), knowledge sources, and conversation starters. You define what the agent should do and give it the context it needs. Then you decide how it gets triggered.
Atlassian ships several out-of-the-box Rovo Agents in Rovo Studio's library, including the Issue Organizer, the Readiness Checker, and a Deep Research agent. These are a good starting point if you want to see agents in action before building your own — Atlassian even publishes four ready-made automation templates using Rovo Agents as a starter kit.
Custom Rovo Agents are where things get interesting: you build one tailored to a specific workflow, like triaging bugs, running sprint retrospectives, onboarding new hires, or managing sprint and release cadence.
The rest of this walkthrough is about the custom agent Oleksandra built.
The use case: sprint and release cadence at TitanApps
TitanApps ships one release per sprint. Every two weeks, the same handful of tasks needs to happen:
- Create the next sprint and the next release version.
- Assign issues to the current release once they hit "Ready for Release" status
- Give the PM a way to see what each ticket actually delivered without re-reading the entire comment thread.
- Transition every issue to "Released" when the version goes out, and draft release notes to go with it.
The manual version of this loop leaks time everywhere. QA doesn't always know what's in the release until issues are manually versioned. Comment threads sprawl, and the PM ends up scrolling through them looking for the "did we ship this or not" decision. Release notes get rewritten from a blank page every fortnight.
Oleksandra Sokol, Product Lead at TitanApps, framed the core frustration this way:
I open a ticket and I see this long thread of comments. Should we solve this or not? Does this case need documentation? I don't want to re-read everything. I just want to see the summary of what happened.
Four things needed to happen automatically, on the right trigger, with the right actor doing them.
Automation vs. agent: what belongs where
Before opening Rovo Studio, it helps to be clear about which tasks belong in automation rules and which belong in a Rovo Agent. The split isn't between "AI things" and "non-AI things." It's between structural work and analytical work.
|
Task type |
Where it belongs |
Why |
|
Create sprints and release versions |
Jira Automation |
Deterministic. No reasoning required. |
|
Assign issues to a version on transition |
Jira Automation |
Same as above. |
|
Transition issues to "Released" when a version ships |
Jira Automation |
Same. |
|
Summarise a comment thread into a release-ready note |
Rovo Agent |
Needs reading, judgment, natural language output. |
|
Draft release notes from a set of released issues |
Rovo Agent |
Same as above. |
Automation for Jira handles structure quickly and predictably. Rovo Agents handle analysis and language generation. The Sprint & Release Manager use case needed both, wired together in one flow.
Building it, step by step
Step 1: Start with a prompt in Rovo Chat
Oleksandra didn't start by writing automation rules herself. She started with a prompt in Rovo Chat, describing all four things she wanted the system to do. Rovo came back with a four-rule plan, and each rule had a "Build automation" button that scaffolded the rule directly in Automation for Jira.
The workflow became: paste the prompt, review Rovo's plan, click "Build automation" for each rule, verify what it produced, fix the small errors, and save.
Oleksandra described the process this way:
In this stage I didn't do anything by myself. I just followed the instructions Rovo suggested. Step one, step two, step three. I clicked Build automation, looked at what Rovo prepared, tested it, and there were some small fixes. The simple rules worked perfectly.
For anyone new to Jira Automation, this is a genuinely useful onboarding pattern. You get working rules you can then read, modify, and learn from, instead of staring at an empty rule editor.
Step 2: The four automation rules
Rovo scaffolded four rules. Three of them were straightforward. One required a workaround.
Rule 1: Create Next Sprint and Version. Trigger: sprint started. Actions: create a smart-value variable ({{nextSprintNumber}}), create the next sprint, create a matching release version. When sprint N starts, the placeholder for sprint N+1 and version N+1 appears immediately. That timing matters because planning for the next sprint happens during the current one, not after it closes.
Rule 2: Assign Issue to Current Release. Trigger: work item transitioned to "Ready for Testing." Action: edit work item fields, set Fix versions to the next unreleased version. Simple, deterministic, one-pass build. QA now sees exactly what belongs in the current release version.
Rule 3: Review Issues Ready for Release (first pass). Trigger: work item transitioned to "Ready for Release." Action: use Rovo with a raw prompt, then add a comment to the work item using {{rovoResponse}}. This is where the new "Use Rovo" action in Automation for Jira comes in — it's the entry point for AI inside automation rules (the Atlassian Automation team's announcement has more context on when to reach for it). You give Rovo a prompt, it returns a response, and you use that response in the next action. The first version of this rule used a raw prompt asking Rovo to summarise what changed, what was user-facing, and what mattered for the release. It worked. The output was just too thin. More on that in Step 3.
Rule 4: Generate Release Notes on Version Release. This one was the hard one. Automation for Jira has no native action for writing to a version's release notes field. You can generate the text with Rovo. You can't write it to the version through the standard action menu.
The workaround: use a web request to hit the Jira REST API directly. The rule structure looks like this — trigger on "Version released," look up work items in the version, use Rovo to generate the release notes, transition each work item to "Released," and send a web request PUT /rest/api/3/version/{{version.id}} with the release notes as the version description.
Oleksandra's take on why this one was painful:
This was the hardest to build. Rovo did well on generating the notes. But there's no automation action to actually add them to a version. I had to do it with a web request, which is more complex and not as clean.
If Atlassian adds a native "update release notes" action in the future, this rule gets simpler. For now, the web request pattern works.
Step 3: Extract instructions into a dedicated agent
Raw prompts inside "Use Rovo" actions have a limit. Short prompts produce short, underspecified summaries. Longer prompts stuffed into the automation rule editor become unmaintainable, and you end up with the same prompt duplicated across multiple rules.
The fix was to build a dedicated Rovo Agent — the Sprint & Release Manager Agent — with proper instructions:
- Agent Purpose. "You are a Sprint & Release Manager agent that analyses Jira issues and creates user-value-driven release notes with a product manager mindset. You focus on user impact, technical accuracy, and meaningful summaries based on actual evidence."
- Core Analysis Principles. Be skeptical, never fabricate. Act as a product manager, focused on user impact and business value. Base all summaries on actual issue content, comments, and links. Prefer a short, accurate summary over a padded one.
- Issue Analysis Framework. Story = user-facing feature or functionality improvement. Bug = defect that impacts user experience or system functionality. Task = technical improvement, refactoring, or internal process change.
- Red flags to avoid. Fabricating information not in the issue. Creating summaries with no supporting evidence. Ignoring linked customer requests.
Oleksandra didn't write the instructions from scratch. She described what she wanted and had Rovo generate the agent, then edited from there.
Two benefits fell out. The output got more accurate because richer instructions produced sharper summaries. And the agent became reusable: the same agent could be called from automation rules, invoked from Rovo Chat, or triggered directly on a Jira work item. One place to update, many places to use. (For a similar "agent-as-language-transformer" pattern, see this Community walkthrough on generating customer-friendly idea descriptions.)
Step 4: Swap "Use Rovo" for "Use Agent"
The rules stayed the same. The action inside them changed. "Use Rovo" (raw prompt) became "Use agent" pointing to the Sprint & Release Manager Agent, with the prompt "Create the issue summary for {{issue}}." The comment posted to the work item now used {{agentResponse}} instead of {{rovoResponse}} (Atlassian's docs on the agentResponse smart values cover the different output formats — markdown, ADF, wiki markup, raw JSON — and this Community walkthrough on using agentResponse has practical examples).
The visible difference in the ticket is important. Comments produced by the agent are attributed to it. Readers can see at a glance which comment came from a person and which came from the AI.
Oleksandra highlighted this trust-and-transparency angle:
You can leave a comment as an agent. In that case you know the comment came from the agent and you need to verify it. If you see a comment that looks like it came from a real user, you might not realise it's actually AI-generated. Attribution matters.
The same swap applied to Rule 4, where the agent now generates the release notes text and the web request writes it to the version.
Step 5: Five ways to invoke a Rovo Agent
The automation rule path is one way to trigger an agent. It's not the only way. Depending on the workflow, one of the other four might fit better. (For a broader tour of what people are building, this Community discussion — My Rovo Use Cases in Jira Service Management — is worth a read.)
|
Trigger method |
Best for |
Caveat |
|
Rovo Chat |
Ad-hoc questions, one-off exploration |
Manual, not scheduled |
|
Automation rule ("Use agent" action) |
Repeatable workflows tied to triggers or transitions |
Team can't always see the agent is running |
|
Issue view "Agents" button |
On-demand analysis of a specific issue |
Requires a manual click |
|
Enabled on a Workflow Status column |
Recurring analysis at a specific stage of a workflow |
Agent must be surfaced on Work items (see below) |
|
Assigned to a Jira work item like a teammate |
Delegating a specific task to an agent |
Behaviour is inconsistent — sometimes the agent acts, sometimes it waits |
Oleksandra's favourite is the workflow status placement. Add the agent to the "Ready for Release" column, and it runs on every issue that enters. Team members see a small agent badge on the column, so it's clear an agent is doing work at that stage.
This is where she pushed hardest on transparency for the team:
Why do I love this? Because it's more transparent for the team. When you go into automation rules, your team doesn't always know an agent is in action. This little agent adds visibility. When the issue transitions, you can see the agent will work on it.
For teams still building trust in AI-driven work, that visibility is worth as much as the automation itself.
Making agents visible on work items
Here's a gotcha worth calling out. To surface a Rovo Agent on the Jira work item view (the "Agents" button in the issue), it's not automatic. You have to enable it manually.
Go to Rovo Studio > your agent > Configuration > Surfaces, and toggle on Work items. The same panel controls whether the agent shows up in other surfaces too — the Rovo browser extension, Slack, the customer portal in Jira Service Management, and the help center.
Oleksandra expected this to be on by default. It isn't. If your agent seems invisible when you go to trigger it manually, this is the first place to check.
Permissions and collaborator roles
Agents have their own permission layer, separate from your Jira user permissions. Two collaborator roles exist:
- Manager can edit the agent and invite other collaborators.
- Editor can edit the agent.
Agents can also carry a verification badge ("Verified by your organisation"), which admins can set on internal agents.
One honest note: the exact relationship between a user's Jira permissions and what an agent can do on that user's behalf is still evolving. If an agent takes actions like editing custom fields or updating schemes, test it with a low-permission user before rolling it out broadly. Don't assume the agent inherits or is bounded by the invoking user's permissions in every case.
When Rovo Agents are worth it (and when they're not)
Not every workflow benefits from an agent. Some are better off as plain automation. Some are better off manual. (For more real-world scenarios where teams found Rovo pulled its weight, this Community piece on real-time use cases of Atlassian Rovo is a useful catalogue.)
Worth building an agent for:
- Your team is nervous about writing automation rules from scratch. Rovo can scaffold something functional, and you can learn from what it produces.
- The task involves reading, summarising, or drafting language — comment threads, release notes, ticket triage, PRD summaries.
- You need a repeatable "product manager brain" applied to routine analytical work.
Skip the agent when:
- You already know Jira Automation well and have complex rules working. Building from scratch with rules you already trust is faster than getting Rovo to scaffold and then correcting its output.
- The task is purely structural — create an issue, transition a status, set a field. Native automation actions do this faster and more reliably.
- No native automation action exists for the target action (like writing to release notes). Weigh whether the web-request workaround is worth it, or whether a simpler manual step will do.
Oleksandra put her honest read this way:
If you already know how Jira Automation works and have complex setups, using Rovo won't feel natural. It's a bit tricky. Building from scratch with rules you know will work is easier than relying on Rovo. But for users who are afraid of automation rules — business teams, or people new to Jira — Rovo is a great help. It can even help you discover what can be automated in the first place.
That last part is the underrated use. If you don't know what's automatable, describing the problem to Rovo and letting it propose rules is a fast way to find out.
What's next
The Sprint & Release Manager Agent is doing the job it was built for. What's on the exploration list from here:
- Skills as reusable actions. Chaining agents that call other agents, so a "release manager" agent can hand off to a "documentation agent" that writes to Confluence when the release notes are ready.
- The chat-agent behaviour. Assigning an agent to a Jira work item behaves inconsistently right now. Sometimes the agent takes action. Sometimes it waits for input. Worth mapping when each mode fires.
- Rovo Agents for the customer portal. Surfacing an agent inside Jira Service Management for first-pass ticket triage before a human agent picks up.
- More custom Rovo Agents for other repeating cycles. Retrospective prep. Onboarding checklists. Release readiness checks. Post-mortem write-ups — this Community walkthrough on automatically generating postmortem documentation with Jira Automation and Rovo is a great follow-on read.
If you've built a Rovo Agent for a workflow of your own, I'd love to hear what worked and what you had to work around. Drop it in the comments.
FAQ
What's the difference between Rovo Chat, Rovo Search, and Rovo Agents?
Rovo Chat is a conversational assistant you interact with in a chat interface. Rovo Search is Atlassian's enterprise search across connected tools: Jira, Confluence, Google Drive, Slack, Bitbucket, and other SaaS apps you've hooked up. Rovo Agents are customisable AI agents with their own instructions, skills, and knowledge sources. Chat is where you ask questions. Search is how you find information. Agents are what carries out the work.
Can Rovo Agents run inside Jira Automation rules?
Yes. Automation for Jira now includes a "Use Rovo" action (for raw prompts) and a "Use agent" action (for pre-built custom Rovo Agents). Both return a response variable you can pass into the next action in the rule — for example a comment, a field update, or a web request. This is the primary path for turning an agent into a scheduled or triggered piece of your Jira project workflow.
Do I need admin permissions to build a custom Rovo Agent?
You don't need Jira admin permissions to create an agent in Rovo Studio, but you do need Atlassian Intelligence and Rovo enabled on your Jira instance. Surfacing the agent in specific places — like a workflow status column or the customer portal — may need extra configuration by an admin. Check your Rovo Studio access before starting a build.
Can a Rovo Agent write to release notes automatically?
Not through a native automation action. You can generate the release notes text with a Rovo Agent, but writing them to the version itself requires a web request to the Jira REST API (PUT /rest/api/3/version/{{version.id}}). If Atlassian adds a native "update version" action in the future, this workaround goes away.
Are Rovo Agents available in Jira Data Center?
Rovo is Atlassian Cloud-native. Data Center connectors and integrations vary by Atlassian product and are worth checking against Atlassian's current documentation for your version. Teams on Data Center that want to work with an LLM today typically go through third-party integrations or the API directly.
What about Rovo Dev and the Rovo CLI?
Rovo Dev is Atlassian's coding-focused Rovo product, aimed at software engineers. It's a different surface from the Jira-based Rovo Agents in this article. Rovo Dev works in developer environments and exposes a CLI for code generation, review, and repo-level tasks. If your team's primary use case is engineering rather than Jira workflow automation, Rovo Dev is the entry point to look at first.
Can Rovo Agents read from Confluence pages and PRDs?
Yes. When Confluence is a connected knowledge source, agents can pull from linked pages, PRDs, meeting notes, and knowledge cards. The Teamwork Graph handles the cross-product context, so an agent working on a Jira work item can pick up related Confluence content without you passing it in manually.
Related resources
Learn more about Smart Checklist on Atlassian Marketplace
Was this helpful?
Thanks!
Viktoriia Golovtseva _TitanApps_
2 comments