From Time in Status Dashboard for Jira to Time in Status Reporter for Jira — Why the Change and What

[#1]

Over the past year, Time in Status Dashboard for Jira has grown far beyond its original purpose. What started as a simple way to measure how long issues spent in each workflow status has steadily evolved based on feedback from teams using it day-to-day.

That evolution led to a natural question:

Is this still “just” a dashboard?

The honest answer is no — it’s now a full reporting tool.
So, to better reflect what it actually does, the app has been re-branded to:

Time in Status Reporter for Jira

Nothing changes for existing users in terms of access or pricing — the new name simply matches the reality of the product.

---

Why a “Reporter” Instead of a “Dashboard”?

A dashboard is something you look at.

But users needed more than that — they needed a way to:

✔ Analyse workflow behaviour
✔ Compare patterns over time
✔ Export raw data for deeper analysis
✔ Build their own insights, not just view charts
✔ Define how they want cycle time to be calculated

So the app has shifted from being a visualisation tool into a reporting and analysis tool — one that gives teams control over how work is measured.

---

Introducing: Groups & Custom Cycles

One of the biggest changes is support for Groups (cycle definitions).

Different teams — and even different issue types — often define cycle time, lead time, or other workflow phases differently. Now you can:

🔹 Define your own cycles

Choose which statuses belong to each phase — for example:

• To Do → In Progress → Code Review might be “Development Time”

• Waiting for Customer might be “Blocked Time”

🔹 Configure cycles per issue type

Because workflows differ, cycle definitions can now differ too.

🔹 Global or user-level cycles

• Global cycles — defined by admins and shared across the organisation

• User cycles — personal definitions when flexibility is needed

All definitions are stored in Forge storage, so they persist automatically.

This was one of the most-requested capabilities — and it’s now built-in.

---

New Reports Beyond Standard Time in Status

Time in status is still there — but it’s only the beginning.

The app now includes several reporting modes:

📊 Assignee Time in Status

Shows how long each assignee kept an issue in each status — useful for workload and bottleneck analysis.

📊 Average Time in Status

For each status, see:

• Average time

• Median

• Minimum / Maximum

• And also view & export the issues behind the calculation
  (not just the aggregated number)

📊 Status Entrance Date

Reports the date each issue first entered each status — helpful for audit, compliance, or SLA tracking.

📊 Time in Status (Enhanced)

The original report — now with:

• Pivot views

• Counts of how many times issues entered a status

• CSV export for deeper reporting

---

Charts — Including Stacked Views Over Time

Every report now supports multiple chart types:

• Bar

• Horizontal bar

• Pie

• Stacked bar

• Horizontal stacked bar

Stacked charts support time cadence bucketing, including:

🗓️ Day
🗓️ Month
🗓️ Year

Meaning you can visualise events across time — not just totals.

---

CSV Export Everywhere

Reports aren’t useful if the data is trapped inside the UI.

So export is available across the board — including:

✔ Time in status
✔ Assignee time in status
✔ Average time in status (with the underlying issue list as well)
✔ Counts and pivots

This keeps the tool compatible with:

• Excel

• Power BI

• AI tools

• Data warehouses

Because sometimes raw data is the real value.

[Metricus]

Great evolution — and I think the shift from “dashboard” to “reporting” makes a lot of sense.

Time-in-status data is a really solid foundation for understanding workflows, especially when teams need flexibility around cycle definitions, exports, and historical analysis.

One thing we’ve seen repeatedly, though, is that once teams have this data, the next question becomes “So what should we actually change?”

That’s where tools like AI Process Optimizer for Jira tend to complement Time in Status reporting rather than replace it. We use process mining and AI on top of the raw status data to show:

• How work really flows end-to-end (including rework, loops, and waiting)
• Where cycle time is inflated by process design rather than effort
• Which workflow or automation changes are likely to deliver the biggest improvement

In other words, Time in Status tells you what happened — process mining and AI help answer why it happened and what to do next.

It’s encouraging to see more tools moving beyond simple charts toward deeper workflow understanding.

[Calogero Bonasia]

I find your semantic evolution particularly compelling because I've explored similar dynamics in my article on insurgent ontologies (https://www.stultiferanavis.it/la-rivista/ontologie-insorgenti-citta-codice-e-complessita-oltre-lordine-moderno). The shift from "Dashboard" to "Reporter" isn't merely a rebranding operation—it reflects an epistemological transformation in how we relate to data.

What you're proposing is a transition from passive visualization to active analysis, returning to users the capacity to autonomously define their own measurement cycles. This methodological self-determination—the ability to configure custom cycles per issue type—recognizes that no universal metric exists, but rather that each team constructs its own system of signification for work.

CSV export thus becomes not an accessory feature, but an acknowledgment that value resides in data openness: allowing the narratives produced by your tool to be interrogated, contextualized, and reinserted into other analytical ecosystems represents a significant choice of methodological transparency.