How to Track Jira Status Transitions and Improve Cycle Time Accuracy

[#1]

Hi everyone 👋

Over the past months, we’ve received a lot of feedback from teams who use Jira not just for tracking work, but for understanding how work actually flows.

Based on that, we’ve recently introduced two improvements in Time in Status Reporter for Jira , one of the apps released by our team, that focus on deeper workflow visibility and more realistic time calculations.

---

🔄 New Report Type: Transitions Count

A common question we see in the Community is:

“How many times did issues move from one specific status to another?”

Most reporting focuses on how long issues stay in a status. But when you're analyzing workflow health, rework, or bottlenecks, you also need to understand movement patterns.

To address this, we added a new report type:

Transitions Count

It shows how many times issues transitioned from one status to another across your selected scope.

What you can do with it:

• View clear From → To transition counts

• Switch between Columns view and Rows view

• Visualize data using:

  • Bar charts

  • Stacked bar charts

  • Pie charts

This makes it easier to identify:

• Reopen loops

• “Ping-pong” between Review and In Progress

• Bottleneck transitions

• Unexpected workflow paths

It complements time-based metrics by showing not just duration, but process behavior.

---

🗓 Improved Calendars (Global & User-Level)

Accurate time metrics depend on accurate working schedules.

We’ve expanded the Calendar functionality to support more realistic and flexible setups.

Calendars can now be configured as:

• 🌍 Global calendars (defined by admins for the entire organization)

• 👤 User-level calendars (created by individual users or teams)

This allows standardized KPI reporting while still supporting regional or team-specific working models.

---

What’s Different About the Calendar Setup

✅ Different time slots per day of the week

Each weekday can have its own schedule.

For example:

• Monday–Thursday: 09:00–18:00

• Friday: 09:00–15:00

• Saturday: custom support hours

Many teams don’t operate on identical daily schedules, so this flexibility matters.

---

✅ Multiple time slots per day

You can define:

• Split shifts (e.g., 09:00–12:00 and 13:00–17:00)

• Night shifts

• Partial-day coverage

• Rotational models

This is especially useful for:

• Support teams

• Distributed organizations

• SLA-driven workflows

---

✅ Preventing overlaps instead of validating after

Instead of allowing overlapping or duplicate time ranges and then showing validation errors, the UI prevents invalid selections from being created in the first place.

This reduces friction and speeds up configuration — especially for admins managing multiple schedules.

---

✅ Propagate settings across days

If your working hours are similar across weekdays, you can configure one day and propagate those settings to others.

It keeps setup efficient while still allowing full customization when needed.

---

Why This Matters for Metrics

Without proper calendar configuration:

• Nights are counted

• Weekends are counted

• Holidays are counted

• Cycle Time and Lead Time become inflated

With flexible calendars applied:

• Reports reflect actual working time

• SLA measurements become realistic

• Cross-team comparisons become meaningful

• Metrics align better with real effort

---

These updates were driven directly by real-world reporting needs — especially from teams trying to go beyond “total time” and understand workflow quality and accuracy.