Five custom Rovo AI agents for flow triage, release reviews, process evidence, and sprint retrospectives
Rovo can read a Jira work item’s summary, description, comments, and fields. But the reason work slowed down is often not written in any of them.
It is hidden in the workflow history.
A work item may have spent eight days waiting for review, entered testing four times, moved back to Development twice, or changed assignees at every handoff. Those events are visible in Jira, but turning them into a useful explanation normally requires a Jira time in status report, several calculations, and a person who knows what to investigate.
This is where a custom Rovo agent becomes more useful.Time in Status tools give Rovo AI in Jira access to calculated workflow evidence such as status duration, repeated status entries, transition loops, assignee time, flagged time, and sprint metrics. Combine those calculations with Jira or Jira Service Management tools, and the agent can find relevant work, interpret the evidence, and prepare a follow-up action.
Rovo provides the reasoning. Time in Status provides the workflow evidence. Jira and JSM tools provide the context and follow-up actions.
Disclosure: I’m part of the SaaSJet team, which develops Time in Status for Jira.
How Time in Status gives Rovo evidence it can use
If you are researching how to calculate time in status in Jira, the calculation starts with the work item’s transition history. Each interval begins when the item enters a status and ends when it leaves. When the item enters the same status several times, those intervals can be added together.
A standard Jira time in status report presents this evidence in a table or chart. A Time in Status Rovo tools makes a specific calculation available inside an agent conversation.
For example, an agent can use separate tools to retrieve:
- total time accumulated in each status;
- the number of times a work item entered each status;
- first entrance dates;
- repeated or backward transitions;
- time associated with each assignee;
- time accumulated while a work item was flagged;
- sprint metrics and comparisons with recent sprints.
The important difference is that the Rovo AI agent does not need to guess from issue text. It can call the appropriate tool and ground its answer in calculated Jira workflow data.
Five Rovo agent patterns for Jira teams
Agent | Recurring question | Evidence it uses | Decision it supports |
|---|
Flow Triage | Which active work items need attention? | Time in Status and flagged time across selected work | What the team should inspect first |
Workflow Detective | Why did this work item take so long? | Status duration, entrances, transitions, and assignee time | Which part of the workflow deserves investigation |
Release Flow Reviewer | Which release work items may require attention? | Time in Status and flagged time for unresolved version work | What to discuss before the release |
Process Evidence Builder | Did the work item pass through the expected stages? | Entrance dates, status counts, transitions, and duration | Where observed history differs from the documented process |
Sprint Retrospective Coach | What should the team discuss in the retrospective? | Sprint metrics, workflow duration, carryover, scope change, and flagged time | Which evidence-based question and experiment to take into the next sprint |
Flow Triage
Flow Triage reviews a selected group of active work items and produces a short, evidence-based attention list.
The agent first uses Jira’s Search with JQL tool to identify the scope. It then compares Time in Status values and, when relevant, the time items remained flagged. Instead of returning every item, it ranks the strongest workflow signals and explains why each one deserves attention.
Useful signals include:
- significant time in an active, review, testing, approval, or waiting status;
- flagged time concentrated in one stage;
- several work items accumulating time in the same stage;
- an open status interval in which time continues to accumulate.
The result is not a list of people to blame or a claim that deadlines will be missed. It is a shortlist of work the team should investigate.
Workflow Detective
Workflow Detective is designed for one work item. It reconstructs the item’s history and separates confirmed evidence from possible explanations.
It can show:
- where the item accumulated the most time;
- how many times it returned to a status;
- which transitions repeated;
- when it first reached an important stage;
- how ownership changed across the lifecycle.
The wording matters. “The workflow history shows three returns from Testing to Development” is evidence. “The acceptance criteria were unclear” is only a hypothesis unless Jira data confirms it.
That distinction makes the agent useful during reviews and retrospectives without turning workflow metrics into an individual performance score.
Release Flow Reviewer
Release Flow Reviewer combines version context with workflow duration.
It retrieves the Jira version, finds unresolved work assigned to it, and reviews up to 40 selected work items at a time. The output highlights items with concentrated time in Review, Testing, approval, waiting, or another relevant stage.
This is a workflow review, not a release forecast. The agent should not claim that an item will miss the release date. Its job is to identify evidence that deserves attention before the release conversation.
Process Evidence Builder
Process Evidence Builder compares the documented workflow with the history Jira actually recorded.
Connect a Confluence page that defines required stages, allowed transitions, optional steps, and review requirements. The agent can then compare that knowledge with status entrance dates, duration, status counts, and transition history.
For each expected stage, it can report:
- whether the stage was entered;
- when it was first entered;
- total time accumulated there;
- how many times it was entered;
- relevant incoming and outgoing transitions.
This creates a traceable process summary. It should not declare legal or regulatory compliance. It presents workflow evidence and highlights missing, repeated, or unexpected steps for human review.
Sprint Retrospective Coach
The Sprint Retrospective Coach connects Jira sprint reporting with the work-item evidence behind the metrics.
It can review completion, carryover, scope added or removed after the sprint started, velocity compared with recent sprints, work-type distribution, flagged time, and stages where sprint work accumulated.
When a metric needs deeper investigation, the agent uses JQL to select a smaller group of work items and analyzes their Time in Status values. It then converts the strongest findings into retrospective questions and proposes one small experiment for the next sprint.
For example:
Seven work items reached Testing during the final two days of the sprint, and four carried over. What limited earlier testing, and what is one change we can test next sprint?
That is more useful than asking the agent to produce generic retrospective advice. Every question should connect to evidence from the Jira sprint report or the workflow history.
Configure the agent instead of “training” it
Teams sometimes search for Jira Rovo training, but creating a custom agent is not the same as training a new AI model on your Jira data.
In Rovo Studio, you configure four practical elements:
- Instructions define the agent’s role, investigation sequence, guardrails, and response format.
- Tools give it access to specific calculations or actions.
- Knowledge supplies team-specific context such as required workflow stages or review rules.
- Conversation starters show people which requests the agent is designed to handle.
A focused agent is easier to test than a universal “analyze everything” assistant. Atlassian currently recommends no more than five tools per agent to maintain strong performance.
Create a custom Rovo agent in Studio
- Open the app switcher and select Studio.
- Select Agents, then create a Rovo agent.
- Choose manual setup when you want to configure every field.
- Add the name, description, behavior instructions, and conversation starters.
- Open Tools and select Add tools.
- Search for the required tools using the [Time in Status] prefix.
- Add the Jira or Jira Service Management tools required by the use case.
- Connect a relevant knowledge source when the agent needs team-specific rules.
- Activate the agent and test it with the conversation starters.
- Refine the instructions when answers are too broad, omit evidence, or introduce unsupported assumptions.
Atlassian provides detailed instructions for creating and editing Rovo agents and adding tools to Rovo agents.
Important limits before you build
- Time in Status Rovo tools are available for Jira Cloud.
- Rovo must be enabled, and Time in Status must be installed on the Jira site.
- Agents respect the permissions of the person using them.
- Time in Status tools read and calculate workflow data. They do not edit work items or move them between statuses.
- Jira and JSM tools can perform actions such as adding comments or updating labels. Rovo asks for confirmation before consequential actions.
- The multi-item Time in Status tool accepts up to 40 work item keys per request.
- Broad requests or items with long histories may reach the Forge execution limit. Narrow the scope and try again when this happens.
- Atlassian recommends using no more than five tools per agent.
There is also an important automation limitation: a Rovo agent triggered through Jira automation cannot use its own tools. It can return text through the {{agentResponse}} smart value, but the six templates in this article are intended primarily for on-demand conversations in which the agent can call its Time in Status, Jira, or JSM tools.
Three guardrails that make the answers trustworthy
Separate facts from hypotheses
Use phrases such as “the workflow history shows” for observed evidence and “this may indicate” for possible explanations. Never invent a reason for a delay or root cause.
Measure the workflow, not the person
Assignee time shows ownership and handoffs. It should not be used to rank people or judge individual productivity.
Keep the evidence set small enough to inspect
When a sprint, release, or project contains more than 40 work items, narrow the scope by status, priority, work type, component, or another relevant field. A focused analysis is more useful than a broad answer that hides the evidence.
Start with one question your team repeatedly asks
You do not need five agents on day one.
Start with the question that already consumes meeting time:
- “Which active items need attention?” becomes Flow Triage.
- “Why did this item take so long?” becomes Workflow Detective.
- “What should we discuss in the retrospective?” becomes Sprint Retrospective Coach.
Give the agent the minimum set of tools, test it against real Jira history, and check whether every conclusion points back to evidence your team can inspect.
That is where Atlassian Rovo AI becomes more than a chat interface. A well-configured Rovo agent for Jira can turn workflow history into a structured investigation—without asking the model to guess what happened.
Explore the complete Time in Status Rovo tools reference or try Time in Status by SaaSJet on Atlassian Marketplace.
