Ticket Mess

When I joined a project as a PM, the first thing I did was triage the tickets.

I have seen teams of every size. Few of them managed their tickets well. The tool was always there. Jira, Redmine, Linear, whatever. The tool existed. The practice was broken.

The most common failure was mixed granularity. "Implement login" sat next to "Ask Yamada about the spec" on the same board. A milestone and a personal reminder, treated as equals. You could not tell what mattered. When everything looks equally important, nothing is.

Purpose and means were often swapped. Closing tickets became the goal. Why the ticket existed, whose problem it solved — none of that was written down. A ticket labeled "API implementation" tells you nothing if you do not know what the API is for. You cannot judge priority without purpose.

I usually started by reorganizing around user stories. "As X, I want Y, because Z." That sentence went on the parent ticket. Child tickets broke it into tasks. Design, implementation, tests. Children are means. The parent speaks the purpose.

People cannot gauge importance when they do not understand why a task exists. But share the thing you are trying to achieve, and they will figure out the how on their own. Aligning on purpose mattered far more than getting ticket granularity right.

I write all this like I know better, but my own side projects have no ticket management at all. The cobbler's children go barefoot.