The Hot Potato Problem: How Ticket Reassignment Churn Inflates Cycle Time

Every engineering leader has seen the ticket that has been "in progress" for a month, with four names in its history and a comment thread that starts with "not sure this is ours". Very few can say how many of those tickets exist, or how much delivery time they absorb — because no standard report counts hand-offs.

The Friction: Work That Belongs to Everyone and No One

In a team of eight, a ticket that changes owner is a conversation at stand-up. In an organization of 1,200 engineers across 60 Jira projects, reassignment becomes invisible for structural reasons:

• Triage is a routing exercise. Bugs land in a shared project or an on-call rota, get assigned to whoever is closest, and get reassigned when that person discovers the problem is in someone else's service.
• Reorganizations move ownership, not tickets. When teams split or merge, open work is reassigned in bulk — and the new owners inherit context they never had.
• The assignee field is a snapshot. Jira shows who owns a ticket now. It doesn't show, in any standard report, how many people owned it before or how long each of them held it.
• Cycle time averages hide the bounce. A ticket that took 30 days because it changed hands four times counts the same as a ticket that took 30 days because it was hard.

The result: work waits between owners, each new owner starts from zero, and leadership sees slow delivery without seeing why.

Why This Matters: The Real Cost of Ticket Reassignment

The Context Problem

Every hand-off throws away context. The new owner rereads the ticket, reruns the investigation and often reaches a different conclusion. The work done by the previous owner rarely transfers cleanly — so the clock keeps running while progress restarts.

The Accountability Problem

When a ticket has had four owners, nobody feels responsible for how long it took. Retrospectives blame "complexity", and the routing problem that caused the delay is never fixed.

The Data Problem

Ownership reports, on-call metrics and team scorecards built on the Jira assignee assume the assignee did the work. On reassigned tickets, that assumption is often wrong — and every report built on it inherits the error.

The Enterprise Discussion: What Engineering Leaders Are Actually Saying

Tickets "bouncing between teams", bugs that "nobody owns" and work lost in reorganizations come up again and again wherever engineering managers, staff engineers and directors compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/EngineeringManagers, r/jira and r/agile.

The pattern holds: leaders feel the cost of reassignment, but nothing they report on counts it — so the routing problem stays invisible.

How Keypup MCP Measures Ticket Reassignment

The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the data Keypup imports from Jira, GitHub, GitLab, Bitbucket and Azure DevOps. For this analysis, what matters is each Jira issue's current assignees, previous assignees, first assignment date, last assignment date, creation date, closing date, state, workflow status, issue type and project, plus the resolving pull requests linked to it and their authors.

In the prompts below, a hand-off is a previous assignee: a person or team that was assigned to the issue and later removed from it. A hot potato is an issue with two or more previous assignees. Durations are in business days — Monday to Friday, 09:00 to 17:00 UTC by default; adjust the working hours and time zone to match your teams.

1. Running a Reassignment Health Check

The first question: how often does work change hands before it's done?

MCP Prompt:

For Jira issues closed in the last 12 months, show the number of
issues, the share with at least one previous assignee, the share
with two or more previous assignees, and the median business days
from creation to close for issues with no previous assignee and
for issues with two or more.

Output: Reassignment Health Check — Last 12 Months

Key Insight: Almost one ticket in three changes owner before it is done, and one in eleven is passed around at least twice. Those hot potatoes take a median 17.8 business days to close — almost three times as long as tickets that keep a single owner.

2. Measuring What Each Hand-Off Costs

Is reassignment a nuisance, or does every hand-off add measurable time?

MCP Prompt:

Group Jira issues closed in the last 12 months by number of
previous assignees — 0, 1, 2, 3, 4 or more. Show each group's
share of closed issues as columns and the median business days
from creation to close as a line.

Output: Every Hand-Off Adds Days

Key Insight: Each hand-off adds roughly five business days to a ticket. One previous assignee takes the median from 6.1 to 10.4 business days; four or more take it to 31.2 — six working weeks for work that, with one owner, takes just over a week.

3. Finding Out Who Actually Wrote the Code

When a ticket has changed hands, does the final assignee do the work?

MCP Prompt:

For Jira issues closed in the last 12 months that had at least
one previous assignee, classify each issue by who authored its
resolving pull requests: the current assignee, a previous
assignee, someone never assigned to the issue, or no linked pull
request. Show it as a donut.

Output: Who Actually Wrote the Code?

Key Insight: On more than a third of reassigned tickets, Jira names the wrong person. In 21% the code was written by a previous assignee, and in 14% by someone who was never assigned at all. Ownership reports, on-call routing and performance conversations built on the Jira assignee are wrong for these tickets. This comparison only works when each person's Jira and Git accounts are matched to the same Keypup user, and when pull requests reference their Jira issue.

4. Seeing Where Tickets Get Passed Around

An organization-wide rate hides the queues where tickets actually bounce.

MCP Prompt:

As a heatmap, show the share of Jira issues created in the last
12 months that have two or more previous assignees, by project
and issue type. Add the number of issues per project.

Output: Where Do Tickets Get Passed Around?

Key Insight: Hot potatoes cluster in shared queues, not across the board. 27% of Platform bugs and 21% of Identity bugs are passed around at least twice, against 3% to 7% for most Stories. Bugs in a few shared projects are where reassignment concentrates.

5. Tracking Reassignment Month by Month

Is this a steady background rate, or did something change?

MCP Prompt:

By month of closure over the last 12 months, show the share of
closed Jira issues with at least one previous assignee and with
two or more previous assignees, as an area chart.

Output: Is Reassignment Getting Worse?

Key Insight: Reassignment did not drift up — it jumped. The share of tickets with two or more previous assignees went from 6% to 11% between March and April and has not come back. A step change points to a structural event that month — a reorganization, a new triage rota, a team split — rather than to individual behaviour. Keypup shows when it happened; you know what changed.

6. Seeing Where the Time Goes on a Hot Potato

Do reassigned tickets take longer because of the bouncing itself, or because the final owner is slower?

MCP Prompt:

For Jira issues closed in the last 12 months, grouped by number of
previous assignees (0, 1, 2, 3 or more), show the median business
days from creation to first assignment, from first assignment to
last assignment, and from last assignment to close, as stacked
bars.

Output: Where Does the Time Go on a Hot Potato?

Key Insight: On tickets passed around three times or more, the bouncing phase is the longest one: 11.6 business days between the first and the last assignment. The final owner then needs 9.6 days — almost twice as long as on a ticket that never changed hands — because they inherit someone else's half-finished context.

7. Listing the Hot Potatoes Right Now

The last step turns the analysis into a list someone can act on in the next triage meeting.

MCP Prompt:

List open Jira issues with two or more previous assignees. Show
the key, project, issue type, workflow status, number of previous
assignees, whether the issue currently has an assignee, business
days since it was last assigned, business days since creation and
number of linked pull requests. Sort by age.

Output: The Hot Potatoes Right Now

Key Insight: Two open tickets have been passed around and then dropped: nobody is assigned to them now. PLAT-7214 has had four previous assignees in 41 business days. Four of the eight have no linked pull request, so no code has been linked to them yet — these need a named owner in the next triage, not another reassignment.

The Technical Implementation: What Keypup MCP Actually Reads

Every number above comes from fields Keypup already imports from Jira and your Git platforms. It helps to be precise about what they are — and what they aren't.

Hand-Offs Come From Previous Assignees

For each issue, Keypup keeps the list of previous assignees — the people and teams who were assigned and later removed — alongside the current assignees. The number of hand-offs is the length of that list. It records who held the ticket, not how many times the field changed: a ticket bounced back to someone who already held it counts that person once, and that person can appear both as a previous and as the current assignee. A ticket whose assignee was removed without a replacement counts as handed off, and shows as unassigned. Assignment history starts when the issue is first imported into Keypup, so hand-offs made before you connected Jira aren't counted.

Phases Come From Assignment Dates

Keypup records the date a user was first assigned and the date a user was last assigned, along with the creation and closing dates. Unowned time runs from creation to first assignment, bouncing from first to last assignment, and the final owner's time from last assignment to close. Intermediate assignment dates aren't stored, so the bouncing phase is measured as a whole, not per owner.

Business Days Come From a Formula, Not a Calendar

Keypup's BUSINESS_DAYS function counts working time between two dates — Monday to Friday, 09:00 to 17:00 UTC by default — and accepts a different time zone, working hours and working days. It doesn't know about public holidays or vacations: Keypup doesn't import calendars.

Code Authors Come From Linked Pull Requests

Keypup links a pull request to the Jira issues it resolves when the issue key appears in the branch name, title, description or commit messages, and records the authors of the resolving pull requests. Comparing them with the current and previous assignees only works when each person's Jira and Git accounts are matched to the same Keypup user. Issues with no key in any pull request show as "no linked pull request".

Projects, Types and Statuses Come From Jira

The project, issue type and workflow status are read as configured in your Jira instance. The heatmap reflects your own project structure and issue types.

Real-World Impact: Enterprise Case Studies

Case Study 1: European Banking Group

Before Keypup MCP:

• 1,300 engineers across 70 Jira projects
• Cycle time up 40% in the two quarters after a reorganization, with no agreed explanation
• Production bugs routed through a shared triage project

After Keypup MCP:

• The monthly trend showed the share of hot potatoes doubling the month the new team structure went live, which turned a vague "the reorg slowed us down" into a specific routing problem
• The heatmap showed 70% of hot potatoes in two shared projects; triage was changed so that the receiving team must accept or reject a bug within one business day instead of reassigning it onward
• The share of issues with two or more previous assignees fell from 12% to 5% in two quarters, and cycle time returned to its pre-reorg level

Case Study 2: North American E-Commerce Platform

Before Keypup MCP:

• 900 engineers, 3,000+ Jira issues closed a month
• On-call ownership reports built from the Jira assignee
• Staff engineers reporting that they "fix everything and own nothing"

After Keypup MCP:

• The code author analysis showed that on 30% of reassigned bugs, the fix was written by someone who was never assigned, most often by a handful of staff engineers
• Ownership reports now use resolving pull request authors alongside assignees, which made that invisible load part of capacity planning
• Team leads review the open hot potato list in every weekly triage, and no ticket is reassigned a third time without a named decision-maker

Implementation: Getting Started with Keypup MCP

1. Connect Jira and Your Git Platforms

Connect Jira and GitHub, GitLab, Bitbucket or Azure DevOps to Keypup. Issues, their assignees and assignment dates, and pull requests are imported automatically; assignment history builds up from the day you connect.

2. Match Jira and Git Identities

Make sure each engineer's Jira and Git accounts are matched to the same Keypup user, so the comparison between assignees and pull request authors is reliable.

3. Reference Jira Keys in Pull Requests

Ask teams to put the Jira issue key in the branch name or pull request title. Without it, a pull request can't be linked to the issue it resolves.

4. Connect the MCP Server to Your AI Assistant

Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.

5. Set a Baseline, Then Work the List Every Week

Run the health check and the hand-off cost chart to set a baseline. Then bring the open hot potato list to every triage meeting, check the heatmap each month, and watch the trend after every reorganization.

Frequently Asked Questions

What is a hot potato ticket?

A hot potato ticket is an issue that is passed from one owner to another — person or team — before anyone resolves it. In this article, it is a Jira issue with two or more previous assignees.

How do you measure ticket reassignment in Jira?

Count the previous assignees of each issue — the people assigned and later removed — and compare the cycle time of issues with no previous assignee against issues with one, two or more. Keypup MCP does this from the previous assignees, assignment dates and closing dates it imports from Jira.

Why does reassignment increase cycle time?

Each hand-off adds waiting time between owners and throws away context: the new owner has to rediscover what the previous one already knew. Ownership also becomes diffuse, so nobody feels responsible for the total time.

How can we reduce ticket reassignment?

Find where it happens first: shared triage projects, specific issue types and recent reorganizations are the usual sources. Then change routing so tickets are accepted or rejected by the receiving team rather than forwarded, and give every ticket that has been reassigned twice a named decision-maker.

The Bottom Line

A ticket that changes hands four times isn't a hard ticket — it's a routing problem. Keypup MCP shows how much work your organization passes around, and what it costs:

✅ Measuring how often tickets change owner before they are done ✅ Quantifying the cycle time cost of each hand-off ✅ Comparing Jira assignees with pull request authors to see who actually did the work ✅ Showing where tickets bounce, by project and issue type ✅ Spotting step changes in reassignment after reorganizations ✅ Splitting the lifecycle into unowned, bouncing and final-owner time ✅ Listing the open hot potatoes that need a named owner now

Ready to see how far your tickets travel before they're done? Connect the Keypup MCP Server and ask your AI assistant.