The queue that stopped meaning anything

82 tickets sat in “Highest” in the JIRA queue for a legacy SaaS product, assigned to us, unresolved. When we pulled the full history on them, 75 had been re-stamped to Highest on the same day. Whatever had generated that batch was a bulk update, and it had erased any ordering the priority field used to carry.

We only noticed because someone asked us for a sorted summary of what was pending in our Highest queue, and we went to get it.

The CLI that couldn’t answer the question

ops-tools has a wrapper for that JIRA, invoked as ops-cli next and ops-cli view. next is described as returning the oldest ticket in the working queue (priority=Working) assigned to the caller. We ran it expecting something close to the top of the pile.

It returned two tickets. next only reads from the Working tier, not Highest, and Working had exactly two items in it. The command was built to answer what to touch next right now, a single-item pull from a small, already-curated bucket. It was never built to rank 82 tickets against each other, so running it told us nothing about the 75-ticket pile.

That was our wrong turn. We had assumed a wrapper named after the exact workflow we wanted would do the ranking for us. It cost ten minutes of poking at --help output and re-running next against the wrong tier before we gave up on it and queried JIRA directly.

What the raw counts showed

jql = 'assignee = "ops.staff" AND resolution = Unresolved'

282 unresolved tickets total. Broken out by priority:

Highest: 82, High: 136, Working: 2, Medium: 60, Lowest: 1, Low: 1

Of the 82 Highest, 7 were sitting in a Parked/Waiting dev-status, which left 75 that were both unresolved and actionable. Comparing created against updated on those 75 confirmed the bulk stamp: same-day timestamp, no other differentiation. The priority field had stopped meaning “prioritized.” It had become a dumping ground that happened to be labeled Highest.

Ranking on the fields the sweep missed

Arguing with whoever ran the bulk update, or hand-retriaging 75 tickets one at a time in JIRA, was off the table. So we built a second, derived ranking on the same 75 tickets, using fields that still carried real information. We pulled four fields per ticket to stand in for RICE:

  • Reach: components and labels, as a proxy for how much of the product surface a fix touches.
  • Impact: the problem description, stored in an ADF (Atlassian Document Format) custom field, customfield_10104, parsed with adf_to_text() into plain text so we could read what was broken.
  • Confidence: a dev-status custom field, customfield_10514, whose values (Prepared, Prototype, Parked, Waiting) told us how far along the diagnosis already was.
  • Effort: story points, customfield_10022.

None of those four is “priority.” The bulk pass had overwritten priority and left the rest alone, so reach, impact, confidence and effort still held the differentiation priority had lost.

The fetch script hit one snag on the way. Our first version tried to write the pulled JSON straight into a scratchpad path under the session’s project directory, and it failed with a plain FileNotFoundError, because that directory didn’t exist yet and nothing had created it. The second script built the directory and did the fetch and write in one pass.

A ticket, not a retriage

Once the four inputs were in, we scored and ranked all 75, then wrote the whole ranked list into a new ticket created just to hold it, type “NO CODE,” rather than rewriting the priority field on 75 live tickets. Editing the field directly would have meant touching JIRA history on every one of them and asserting an ordering we’d have to defend line by line. The separate ticket left the underlying data untouched and gave anyone opening the queue an answer to “what’s actually next,” sourced from fields the bulk action never reached.

Any status field that bulk operations touch, whether a priority flag, a workflow state or a label, will decay the same way, because a single sweep can overwrite months of individual judgment. The fields that survive are the ones nobody bulk-edits, like story points, descriptions and dev-status notes tied to actual work. When the field you trust goes flat, rank against the ones the flattening didn’t reach.