Issue Reassignment Hotspot Leaderboard(2.5.8)

Some tickets get passed around repeatedly without anyone taking definitive ownership. Each reassignment adds delay, context loss, and confusion. This leaderboard surfaces the tickets with the highest reassignment count so they can be investigated directly.

A ticket that has been reassigned five or six times is not just inconvenient — it usually points to something deeper: unclear requirements, an unacknowledged dependency, or a task that no one wants to take responsibility for. Understanding why helps break the cycle.

What you can conclude

• For tickets at the top of this list with High badges (3+ reassignments), a reviewer could ask what has kept each one from staying with one owner.
• If multiple hotspot tickets belong to the same epic or project area, the problem may be at the requirement or scoping level.
• All-unowned hotspot tickets (NULL current assignee) are the highest priority — they are stuck with no current responsible party.

How this chart works

Ranked horizontal bar chart of issues by total assignee-change count. Color-coded volatility badge: High (≥ 3 reassignments), Medium (= 2), Low (= 1). Also shows the current assignee — NULL means currently unowned.

Use the minimum reassignments filter to focus on the most critical cases only.

What the date range does to this list

• Each row is one issue, and the reassignment count beside it is that issue's all-time total—every handoff recorded for it, not a count of handoffs inside the selected range.
• The range decides which issues are listed, and it does so on each issue's most recent handoff. An issue appears here when that latest handoff falls inside the range.
• So a listed count can include handoffs from before the range started. The number beside an issue can be larger than the activity the range covers, and it should be read as the issue's history to date rather than as a figure for the period.
• And when the end date is in the past, an issue that was handed off again after that date is not listed at all, even though it had handoffs inside the range. Treat the list as a lower bound on the issues handed off during a historical range: the ones most likely to be missing are the longest-running, which are the ones this panel exists to surface.
• With no range set there is no selection rule to apply, and the all-time count is the whole picture.
• For scale, measured on MetaFrazo's own demonstration data on 2026-08-31: a one-month range set two months back listed 199 issues, where 212 issues had at least one handoff inside it.

An owner whose Atlassian account has been erased is shown as "erased account": the issue still has an owner, whose identity has been removed.