On Ticket Management

Published on Sep 17, 2024, filed under development, management (feed). (Share this on Mastodon or Bluesky?)

Issue tracking tools like Jira, GitHub Issues, or Bugzilla are essential for managing bugs and tasks (that is, issues). However, not everyone finds ticket management convenient or convincing. While some developers try to get by only doing minimal ticket work, others manage to get more out of them.

While there’s a line until work with tickets becomes excessive, tickets are crucial for team support and management. I like to use this post to share my view on why tickets matter, how to manage them effectively, and what a healthy issue management culture can look like.

Why Tickets Matter

Tickets provide an overview of our workload and help us prioritize tasks. Centralizing this information in an issue tracker eliminates the need for searching in multiple places, and simplifies work (re)assignment.

Establishing guidelines for ticket handling is essential for consistent practices within our teams and organizations. Tickets also offer less obvious benefits, such as identifying time-consuming tasks and areas of individual and team strengths. (This is what I like to focus on in particular, to check on useful data points.)

Best Practices for Ticket Management

Here are guidelines and principles that, from my experience, make ticket management both effective and efficient. They contain some assumptions (like work with OKR, or the existence of epics); if they don’t hold for you, customize or ignore them.

Ticket Creation

• Every bug should have a corresponding ticket.
• Each OKR should be represented by a ticket, typically an epic with multiple tasks.
• Work that isn’t documented yet and that requires significant time (anything taking more than an hour, perhaps less) should have their own tickets.
• Passive work (that is, work not requiring any action, like meetings) or routine tasks (like managing email) should not be represented by tickets.
• Preferably, every ticket should have an assignee, who may change as responsibilities become clearer.

Ticket Information and Metadata

• Every ticket should have a concise title and description.
• Relevant URLs should be included, when applicable.
• Tickets should be assigned to an appropriate epic.
• The type of ticket may be limited to “task,” “bug,” or “epic” (to avoid ticket type clutter).

Ticket Maintenance

• Any work done on a ticket should be documented by a brief comment.
• Ticket status should be updated whenever it changes.
• Inactivity (if a ticket unexpectedly keeps not being worked on) should be commented on and explained (“heartbeat”).
• Refinements may be limited to the people most familiar with and taking care of the work, in order to keep the process streamlined.
• All tickets being worked on should be in the current cycle (Scrum language: sprint).
• Blocked tickets should be flagged (visually marked).
• Tickets to be monitored (as when assigning them to other teams) are useful to be labeled.
• Tickets that have not seen progress for an extended period of time should be regularly reviewed, reprioritized, and pruned.

❧ While these guidelines may seem detailed, they establish a framework that should feel lighter in practice. Adopting and fine-tuning it, it should allow you to anchor your team’s work, ensure visibility into it, and more efficiently produce results. (And yet, someone will still tell you they don’t like tickets 🙂)