What Tickets Are Bad At

Tickets track work. They're terrible at storing knowledge. A ticket that says "migrate the auth service to the new token format" captures what needs to happen and why — but the resulting architectural decision, the token format spec, and the migration strategy don't belong in the ticket. They belong in documentation that outlives the ticket's lifecycle.

The failure mode is familiar: a team uses tickets as their knowledge base, and six months later, finding the auth migration decision requires searching through 2,000 closed tickets with keywords that match dozens of unrelated results. The decision is in there somewhere — buried in a description, a comment, or an attachment — but it's not findable in any reasonable time.

Tickets are ephemeral by design. They represent a unit of work with a start, an end, and a status. Architecture decisions, API contracts, runbook procedures, and onboarding guides are persistent knowledge that needs a persistent home: a wiki, a /docs directory in the repo, an ADR (Architecture Decision Record) file. The ticket can link to the document. The document shouldn't live inside the ticket.

A 30-comment thread on a ticket is a conversation that should have happened somewhere else. Tickets are coordination tools — they answer "what needs to happen?" and "is it done?" They're not the right medium for design debates, requirement negotiations, or troubleshooting sessions.

When a ticket becomes a chat thread, three things go wrong. First, the signal-to-noise ratio drops: the actual requirements are buried between status updates, tangential questions, and "any update on this?" pings. Second, the conversation isn't visible to people who aren't watching that ticket — a design decision made in a ticket comment doesn't show up in the team's Slack channel, meeting notes, or documentation. Third, the ticket's metadata (status, assignee, due date) becomes disconnected from the reality of a still-evolving scope.

Discussion belongs in discussion tools: Slack threads with a summary posted back to the ticket, design docs linked from the ticket, or a 15-minute call with notes captured in the description. The ticket is the landing page for a piece of work, not the transcript of every conversation about it.

A backlog isn't a parking lot for ideas — but most teams treat it like one. Every feature request, minor bug, "nice to have," and "we should probably do this someday" gets a ticket, and that ticket sits untouched for months. The backlog grows. Nobody prunes it. Eventually you have 800 tickets and no way to distinguish the 30 that matter from the 770 that don't.

Stale backlogs carry real costs. Engineers lose time scrolling past dead tickets in sprint planning. New team members can't tell which tickets are current and which are fossils from two product pivots ago. Searches return noise. The backlog becomes a guilt-inducing monument to work the team will never do — and every glance at it undermines confidence in the planning process.

Backlog hygiene is a discipline, not a one-time cleanup. A healthy cadence: once a month, review every ticket older than 90 days. If it hasn't been prioritized in three months, it's either not important enough to do or not well-defined enough to estimate. Close it. If it matters, it'll come back — and when it does, it'll come back with fresh context and current priorities.

The instinct is to keep tickets open "just in case." That instinct is wrong. A closed ticket isn't deleted — it's searchable, linkable, and reopenable. Closing it just means the team is honest about what's actually in scope. A 50-ticket backlog that reflects real priorities is infinitely more useful than an 800-ticket backlog that reflects every idea anyone ever had.