🔍 Jira issue health: spot risk with Agile Cycle Time Charts 2.4

[#1]

A delayed Jira issue rarely explains itself. You can see that a ticket is late, or that cycle time is rising, but the next question is usually harder: is this specific work item actually at risk, and what happened in its workflow before it got here?

Agile Cycle Time Charts 2.4 brings that investigation into the Jira issue view. The release adds Work item health and Status transition history, so teams can check the current risk signal and then read the workflow timeline without leaving the ticket.

The same functionality is also available in Agile Reports & Gadgets 9.2, so teams using the full reporting bundle can follow the same workflow from the broader app.

🔍 Start with the ticket, not the dashboard

Most flow reports are useful after you already know what you are looking for. A cycle time chart can show that work is slowing down. A time-in-status report can show where a workflow tends to wait. But during standup or triage, the question is often smaller and more immediate:

Is this ticket still progressing normally?

The new Work item health panel answers that directly on the issue layout. It shows whether the work item is on track, needs attention, or is at risk, based on time-based metrics compared with similar completed work.

The benchmark uses completed issues from the same Jira space and the same work item type. For base-level issue types, it looks at the last 3 months of completed work; for epics and above, it uses 6 months. That context matters because a bug, a story, and an epic should not all be judged against the same timing pattern.

For To Do work, the panel helps identify items that have spent too much time waiting in the backlog. For in-progress work, it can surface Time in current status, WIP age, and Lead time. For completed work, it shifts the question toward Cycle time and Lead time. The result is a practical first signal: which tickets are normal variance, and which ones deserve a closer look today?

⚠️ Then inspect where the time went

A health signal is useful, but it is not the full investigation. If a ticket is at risk, the team still needs to know why.

That is where Status transition history fits into the release. The new tab in the Jira issue Activity section shows each status change as a separate row: where the issue moved from, where it moved to, when the transition happened, who made it, and how long the issue spent in the previous status.

This is especially useful for rework and handoff questions. A ticket might look like one long cycle-time outlier, but the transition history can show that it spent two weeks in code review, moved from testing back for fixes, or passed through the same status more than once.

Jira already stores that history. The problem is that raw history is slow to read when you are trying to run a retro, answer a stakeholder question, or understand why one issue became the exception. A structured transition view turns the issue into a readable workflow timeline.

🧩 Use both signals together

The strongest workflow is not one panel or the other. It is the sequence.

Work item health gives the daily signal: this ticket is on track, needs attention, or is at risk. Status transition history gives the evidence behind the signal: which stages it visited, how long it stayed there, and whether it bounced through the workflow.

That pairing changes the conversation. Instead of saying "this ticket feels stuck," a scrum master can ask a more specific question:

• It has been in the current status longer than similar completed issues. Is there a blocker?

• It returned from testing once already. Is this rework or expected review?

• It spent much longer in code review than every other stage. Is that a one-off or a team pattern?

Those are better questions for standups and retros because they point to action. The team can decide whether to split scope, escalate a dependency, improve a Definition of Done, or leave the ticket alone because the timing is still within a normal range.

If the same pattern appears across several tickets, the team can zoom out from the issue view into the broader chart picture: Cycle Time and issue-list analysis in Agile Cycle Time Charts, and WIP-focused reporting in Agile Reports & Gadgets when the team needs the full reporting bundle.

✅ What changed in Agile Cycle Time Charts 2.4

Agile Cycle Time Charts 2.4 adds two issue-view features:

• Work item health: an at-a-glance health status for a Jira issue, with time-based metrics compared against similar completed work.

• Status transition history: a structured Activity tab showing every status transition, the person who made it, the timestamp, and the time spent in each previous status.

Agile Reports & Gadgets also includes the same functionality, so teams using the broader reporting bundle can keep the same workflow.

If your team already uses Jira issue history to understand why work slowed down, this update removes a lot of manual digging. If you are trying to catch risky work earlier, it also gives you a signal before the delay becomes a retrospective surprise.

---

From the Broken Build team behind Agile Cycle Time Charts & Agile Reports & Gadgets