Thread by @jschauma

So You Have A Jira Queue...

A brief Twitter r̶a̶n̶t̶ 🧵 on responsible ticket management, born out of years of frustration:

There's few things as frustrating in a large organization as diligently filing a ticket or reporting a problem only for it to sit there without anybody looking at it until it's closed by some automated job marking it as stale because it hasn't seen any updates in a year.

If you have a product that warrants a ticket queue, then you owe it to your users to manage it just as you owe it to your team to manage their workload.

Proper ticket management helps you set expectations, drive metrics, gain insights, and allow others to rely on you.

Let's start with the lifetime of a ticket.

The details depend on the type of work you do, your organizaton, team size, etc., but at minimum, you still generally have:
- "new/incoming"
- "triaged/accepted"
- "in progress"
- "closed"

That is, you need a process to move them from one state to the other. Incoming tickets need to be looked at by someone.

Revolutionary, I know. But see above re a common frustration of robo-ticket-closing.

So get your queue in order.

Ensure you have some sort of automation in place that notifies you of new tickets. Email to a dedicated mailing list, slack notification, whatever.

Best to spread the workload and ensure all people on the team take shifts triaging incoming tickets.

Ticket triage is, by the way, a great way for senior staff to stay in the loop, just as it is for junior staff to get to know your users and systems.

Don't exempt people; consider pairing juniors with seniors for rapid learning.

Note: the person triaging the ticket does not need to _handle_ the ticket.

Just identify e.g. "completely bogus", "duplicate", "needs more info", "belongs elsewhere", "bug/problem", "feature request", and "security issue" as well as an initial priority and responsible owner.

Once categorized, your ticket becomes "triaged/accepted" (unless it could be trivially closed).

At this point, you probably want to have it be assigned to an individual (for actual work or for further delegation) or a group / team / task force. I.e., the ticket gets an _owner_.

The _owner_ is the party responsible to see that the ticket gets resolved. They may not do all the work themselves, but they find the people who will. They know the issue and can ballpark resolution time.

As the owner, provide the requester with some feedback to set expectations.

Depending on the type of work you do, you may commit to an SLA, but even if you can't, provide some rough info ("next sprint", "next quarter", "needs investigation, will up date in a week", ...).

Remember: a user updating a ticket asking for an ETA does not mean "yo, get cracking, I want this resolved pronto", but rather "please help me manage my work that relies on this".

(Ideally, your users should not have to ask about the status of a ticket, because your SLAs or approximate ETAs for any given ticket state are published. I.e., you help the user manage their time, their dependencies, their workload by owning your promises.)

Have some automation that ensures your tickets don't go stale.

If a ticket is pending feedback or more information from the requester, have the system remind them; if it's blocked by other tickets (in other queues), have the system update those.

Closing as "invalid" or "wontfix" is fine, even if your users won't like it. What's not fine is closing a ticket automatically because it's not seen an update in a long time.

A ticket not being fixed over a long period of time should _increase_ its priority, not _decrease_ it.

While a ticket is actively being worked on ("in progress"), ensure it actually does see updates.

Code diffs, pull requests, design docs, collected metrics, ... link them in the ticket. This helps your users value your work and again sets expectations.

Once a ticket has been closed, ensure it's verified. Use the correct closed state to ensure you get the right metrics: "incomplete" is different from "fixed" is different from "wontfix" is different from "duplicate" is different from "worksforme".

Most of this is not very difficult and a lot of this can be done via automation.

I remain a big fan of having teams rotate through a ticket triage shift, as that helps improve user understanding, team communications, spreads tribal knowledge, and leads to better documentation.

Oh, and if you think I forgot the flip side, how to submit tickets and work them, here's another Twitter Ticket Rant from a while ago:

https://twitter.com/jschauma/status/1007075536202620928

El fin. For now. 🧵✅