How to audit your Status Category mappings
This comes up indirectly in many reporting discussions. Dashboards, sprint reports, cumulative flow diagrams, or control charts that "look wrong" often turn out to have one common cause: Status Category mappings that no longer reflect how work actually flows.
Many of Jira's built-in reports and board calculations rely on Status Categories, not just on the names of individual statuses.
A quick review takes about 15 minutes and often reveals inconsistencies that have been sitting unnoticed for years.
Note for team-managed projects
This walkthrough focuses on company-managed projects, where statuses are managed globally.
If you're using team-managed projects, the same audit principles apply, but you'll review each project's workflow individually because status configuration is managed within the project rather than centrally.
Step 1: Review your global status catalog
For company-managed projects, open:
Jira administration → Work items → Statuses
This page contains every global status together with its assigned Status Category.
Every status belongs to exactly one of three categories:
- To Do
- In Progress
- Done
This is the authoritative mapping Jira uses to interpret where work is in its lifecycle.
Step 2: Audit the mappings
Now comes the actual audit.
Don't ask whether a status name sounds right.
Ask whether Jira interprets the status correctly.
For every status, consider what its category tells Jira.
- To Do means work has not started.
- In Progress means work is currently underway.
- Done means the work is complete.
Now compare that interpretation with what the status actually represents in your own process.
For example:
- Is waiting for a customer really active work?
- Does waiting for support represent work in progress or simply waiting?
- Should waiting for approval mean work has not started, or is implementation already complete and the issue is only awaiting a business decision?
The goal isn't to make every organization use the same categories.
The goal is to make sure the category reflects how your teams actually interpret the status.
Why this matters
Status Categories are more than labels.
They influence how Jira interprets work.
If a status such as Waiting for customer is categorized as In Progress, Jira treats that issue as ongoing work.
If a status such as Approved is categorized as Done, Jira may consider the work complete even though deployment or release has not yet happened.
That may be exactly what your organization intends.
Or it may simply be a configuration that nobody has reviewed since the workflow was created.
The purpose of this audit is not to standardize every workflow.
It is to ensure that the Status Category accurately reflects reality.
Step 3: Verify before you change
If you identify a status that deserves a second look, open it and review its configuration.
Here you'll find the global Status Category assignment.
One important detail is easy to overlook:
A Jira status is a global object.
Changing its Status Category here affects every workflow that uses this status.
Before making any changes:
- Check which workflows use the status.
- Confirm how the teams interpret that status.
- Make sure the new category reflects the intended workflow behavior.
Consistency is more important than forcing every workflow into the same pattern.
Optional: Reality check with JQL
Reviewing the configuration tells you how Jira is configured. A simple JQL search helps you compare that configuration with how the work actually behaves.
Try the following query:
statusCategory = "In Progress" AND updated <= -14d ORDER BY updated ASC
This returns issues that Jira still considers In Progress, even though they haven't been updated for at least two weeks.
The results don't automatically indicate a problem. Some issues may be intentionally waiting for a customer, another team, or an external dependency.
Instead, use the results as a conversation starter:
- Are these issues truly active work?
- Are waiting or blocked states intentionally categorized as In Progress?
- Does this reflect how your teams define work in progress?
If the answer is yes, your configuration is likely aligned with your process.
If the answer is no, you've identified a workflow that deserves a closer review.
Step 4: Validate the outcome
Once you've reviewed or adjusted your mappings, revisit the reports and boards that originally raised questions.
Check whether they now reflect how your teams actually work.
The goal isn't to achieve a "perfect" configuration.
The goal is to ensure that Jira's interpretation of work matches reality, so dashboards, reports, and flow metrics become easier to trust.
Quick audit checklist
✔ Review the global Status list.
✔ Check whether each Status Category reflects the actual workflow.
✔ Pay special attention to waiting, approval, review, and deployment-related statuses.
✔ Remember that changing a Status Category affects every workflow using that status.
✔ Validate the impact in reports and dashboards after making changes.
One limitation of a manual audit
A manual audit gives you a snapshot of your Jira configuration at a specific point in time.
As new projects, workflows, and statuses are introduced, mappings can gradually drift again. That's why many organizations include this review as part of their regular Jira governance rather than treating it as a one-time exercise.
Full disclosure: I'm one of the co-founders of MetaFrazo. We built continuous monitoring for configuration drift because we kept seeing the same issues return over time. That said, the manual audit above is where I recommend every Jira administrator start. You don't need any additional tooling to get value from it.
Was this helpful?
Thanks!
Maria Reisinger
2 comments