How I Built an AI Agent to Audit My Jira Workflow — No Code Needed

[#1]

Have you ever seen Jira claim your team "doing nothing" during a sprint that clearly wasn't empty? Why does a burndown chart refuse to go down even after issues are marked Done? I faced these questions myself while working on a task, and they led me to discover some hidden Jira workflow misconfigurations that can quietly mess up reports.

After I read about this, I set out to fix a few of these problems myself by building a Rovo agent. I didn't need to write any code; I just used a prompt. In this article, I'll share what I discovered, how I built the agent with AI Apps Builder, and what happened when I tested it.

Why Your Jira Reports Might Show Incorrect Data

At first, I needed to study where the data was going wrong. I figured out that most issues come from sprint setup and status mapping. These details might seem minor, but they can quietly break board visibility and reporting.

Problem 1: Wrong Sprint setup

Here are just a few points, for example:

• Starting a sprint with no issues. If you begin a sprint empty and add issues later, Jira can't answer the basic question "did we do what we said we would?" because there was no initial commitment to measure against.

• Estimating after the sprint starts. If you add story points in the middle of a sprint, velocity becomes meaningless. You lose track of what was committed at the start, so comparing sprints doesn't work.

• Adding issues after the sprint starts. Each issue added in the middle of a sprint changes the baseline. The burndown chart jumps up instead of trending down, so it no longer reflects reality.

My colleague explained the sprint setup in detail in her article “How to Use Sprints in Jira Correctly”. It’s worth reading if this is new to you.

Problem 2: Missing status mapping

Jira only counts an issue as done if its status is in the board's rightmost column. If statuses like "Done," "Blocked," or "Canceled" aren't mapped there, those issues won't show as complete and may keep rolling into future sprints. Here's the distinction that trips people up:

Term	What it means
Status	The issue's actual state in the workflow (e.g. "In Progress," "Code Review," "QA Testing," "Done")
Column	What you see visually on the board (e.g. "To Do," "In Progress," "Done")
Mapping	The link between a status and a column. For instance, telling Jira "show Code Review and QA Testing both in the In Progress column"

If your team adds a new status like "Ready for Deploy" to the workflow but forgets to map it to a board column, then the issue moves into that status and disappears from the board. It still exists in Jira, but you can't see it, and it won't show up in reports either.

As a result, the burndown chart doesn't account for the time an issue spent "invisible," so it looks like work has stalled. The velocity chart can show issues as incomplete because Jira never saw them move.

You can check this yourself: open your Jira board → click the "..." (more options) menu in the top-right corner of the board → select Configure Board → go to Board Settings → Layout →Columns. Any status floating without a column assignment is unmapped.

Board filters matter too. The filter controls what appears on the board and in every Agile report connected to it. If it leaves out an issue type or status that exists in your project, those issues disappear from the board, the Sprint Report, and the Velocity Chart all at once.

To check it follow the same pattern: open your Jira board → click the "..." → Configure Board → Board Settings → Details. The board's filter query (the JQL that controls what shows on the board) is displayed there.

Problem 3: Corrupted workflow transitions

Sometimes reports show a curve that just doesn't make sense. For example, an issue gets closed mid-sprint, but the "remaining work" line doesn't move. This usually happens because of a corrupted transition: Jira recorded a transition where the source and destination status are identical, like Done → Done.

This is a technical error in the workflow itself, not something a user does by clicking around. It usually appears when an admin sets up automation or a post-function on the workflow and accidentally makes it re-apply the Done status when an issue transitions into Done. Jira follows that instruction and logs a "Done → Done" transition in the issue's history, which shouldn't logically exist.

The impact on reporting is that the Burndown Chart stops showing the correct amount of remaining work. The issue is technically closed, but the chart doesn't drop because Jira sees a transition it can't process and ignores it when calculating what's left. Sprint Reports that use the same transition history show the same problem.

Where to see it

Open the issue and check its History tab or the workflow transition log. Look for a status change where the "from" and "to" values are the same. If you're an admin, the root cause is usually visible in Space settings → Workflows.

Probem 4: Missing Resolution values

If Resolution isn't set when an issue moves to Done, JQL like resolution = Unresolved returns misleading results. Since dashboards, filters, and reports commonly rely on this field, the impact is wide. Created vs. Resolved charts can misclassify these issues, and an issue that's actually finished can still show up as "unresolved" in a filter — which throws off SLA tracking and time-to-resolution averages.

To check this, run project = YOUR_PROJECT AND statusCategory = Done AND resolution is EMPTY in the issue search. JQL finds empty Resolution values directly, regardless of your project type.

On a company-managed project, open the board's "..." menu → Configure Board → Board Settings → Layout → Columns. Under "Map statuses to columns," check the Set resolution checkbox for each Done-type column.

On a team-managed Space, this specific control isn't available. Atlassian Support confirms this and recommends using an Automation Rule to auto-set the Resolution field whenever an issue transitions to a Done status.

Problem 5: Inconsistent estimation across teams

If one team estimates in story points, another in hours, and a third doesn't estimate at all, velocity and sprint reports become impossible to compare across teams. Velocity stops meaning anything at that scale.

Jira lets each board choose its own estimation statistic, such as story points, original time estimate, or issue count, in the board configuration. Teams often set this independently when they're created, without a shared standard across the organization. Over time, one team's "5" in story points has no connection to another team's "5 hours," but both feed into the same portfolio-level dashboards if nobody notices the mismatch.

Check Board Settings → Estimation on each board to see which statistic it uses. If you're comparing teams at a program or portfolio level, check whether any cross-team dashboard or report is aggregating velocity or story points across boards that use different estimation statistics — that's where the numbers stop being comparable.

Building a Rovo Agent to Catch These Problems

Manually checking all of this across a project takes time, and most Jira admins only notice something's wrong after reports start looking strange. So instead of checking manually, I built a Rovo agent to do it using a plain-language prompt, with no code needed.

I started with this:

Create a Rovo agent that audits a selected Jira Cloud project by checking:

1. Missing resolution — issues with status category "Done" where the Resolution field is empty.

2. Unmapped statuses — statuses used by issues in the project that are not present in any column of the project's board(s).

3. Incorrect board filters — board filter JQL that excludes issue types or statuses actually present in the project.

The agent I ended up with does three things:

1. Conversational intake. It asks which project to audit and which project to create a summary task in, confirms both, and tells you the audit is running.

2. Three health checks:

Check	What it looks for	Where the fix lives
Missing Resolution	Issues in a "Done" status category with an empty Resolution field	Open the issue, set the resolution manually
Unmapped Statuses	Statuses used by project issues that aren't mapped to any board column	Board Settings → Columns
Board Filter Integrity	Board filter JQL that excludes issue types or statuses that actually exist in the project	Board Settings → General

3. A Jira task with the findings. If the audit finds at least one problem, the agent creates a task in the admin or ops project you specify, with a numbered breakdown grouped by check type: location, impact, and recommended fix for each finding. If nothing is found, no task gets created, and the agent tells you directly.

What Happened When I Ran My AI Agent

When I ran my Jira Workflow Audit Agent against two real projects, I got two reports:

1. The project has a Healthy status.

2. The project has 2 issues that need attention.

Jira admins usually don't know a workflow is misconfigured until reports start showing numbers that don't add up. Finding these problems by hand is slow and easy to miss. Having an agent run the check on demand saves real time. Even a simple agent that checks for three specific problems does more than most people check manually.

Plus, I asked my AI Agent to create a Jira Task to track the remediation of these findings, and it did.

Two Ways to Build an AI Agent: Code or No-Code

There are two ways to build an agent like this: you can write the code yourself, or you can describe it in plain language and let AI generate it. I'm a marketer with no engineering background, so I chose the second option.

Two tools currently let you do this: Rovo Studio and AI Apps Builder (the product my team builds). Both let you create apps, agents, and skills through natural-language prompts. One difference worth calling out: AI Apps Builder has Dev Help.

Dev Help connects you directly with the AI Apps Builder team when AI-generated code isn't enough on its own. Their developers can:

• Review the generated code and app structure.

• Fix issues that show up after AI generation.

• Improve or extend existing functionality.

• Add custom logic based on your specific requirements and workflows.

For non-technical users, that's the difference between having an AI in your corner and having both an AI and a person who can actually finish the job when you get stuck. For technical users, it's a second set of eyes on a problem you're already close to solving. As the saying goes, two heads are better than one.

Should You Build a Rovo Agent for This?

Jira's reports are only as accurate as the workflow behind them. Empty sprint starts, late estimation, unmapped statuses, misconfigured board filters, corrupted transitions, missing Resolution values, and inconsistent estimation between teams can each quietly distort what your dashboards show.

You don't need to check all of this by hand. A Rovo agent, built through a no-code platform like AI Apps Builder, can run these checks on request and create a task as soon as something needs attention. Building one doesn't require writing any code, just a clear prompt and a willingness to test the results before you trust them.

Build Your Own Jira Workflow Audit Agent

If workflow health checks like this would save your team time, AI Apps Builder lets you build the agent, skill, or custom Jira app you need. You can describe it in plain language, with no coding required. Install AI Apps Builder for Jira and try building your own audit agent.