Was Tickets schlecht können

Tickets verfolgen Arbeit. Sie sind schrecklich darin, Wissen zu speichern. Ein Ticket, das sagt „Auth-Service auf neues Token-Format migrieren", erfasst, was passieren muss und warum — aber die resultierende Architekturentscheidung, die Token-Format-Spezifikation und die Migrationsstrategie gehören nicht ins Ticket. Sie gehören in Dokumentation, die den Lebenszyklus des Tickets überdauert.

Der Fehlermodus ist vertraut: Ein Team nutzt Tickets als Wissensdatenbank, und sechs Monate später erfordert das Finden der Auth-Migrationsentscheidung die Suche durch 2.000 geschlossene Tickets mit Stichwörtern, die auf Dutzende unzusammenhängender Ergebnisse passen. Die Entscheidung ist irgendwo da drin — vergraben in einer Beschreibung, einem Kommentar oder einem Anhang — aber sie ist in angemessener Zeit nicht auffindbar.

Tickets sind von Natur aus kurzlebig. Sie repräsentieren eine Arbeitseinheit mit Anfang, Ende und Status. Architekturentscheidungen, API-Verträge, Runbook-Prozeduren und Onboarding-Leitfäden sind persistentes Wissen, das ein persistentes Zuhause braucht: ein Wiki, ein /docs-Verzeichnis im Repository, eine ADR-Datei (Architecture Decision Record). Das Ticket kann auf das Dokument verlinken. Das Dokument sollte nicht im Ticket leben.

Ein 30-Kommentar-Thread in einem Ticket ist eine Konversation, die woanders hätte stattfinden sollen. Tickets sind Koordinationswerkzeuge — sie beantworten „Was muss passieren?" und „Ist es erledigt?" Sie sind nicht das richtige Medium für Design-Debatten, Anforderungsverhandlungen oder Troubleshooting-Sessions.

Wenn ein Ticket zum Chat-Thread wird, gehen drei Dinge schief. Erstens sinkt das Signal-Rausch-Verhältnis: Die tatsächlichen Anforderungen sind zwischen Statusupdates, tangentialen Fragen und „Gibt's ein Update dazu?"-Pings vergraben. Zweitens ist die Konversation für Leute, die das Ticket nicht beobachten, nicht sichtbar — eine Design-Entscheidung, die in einem Ticket-Kommentar getroffen wird, taucht nicht im Slack-Channel des Teams, in Meeting-Notizen oder in der Dokumentation auf. Drittens werden die Metadaten des Tickets (Status, Zuständiger, Fälligkeitsdatum) von der Realität eines sich noch entwickelnden Umfangs abgekoppelt.

Diskussionen gehören in Diskussionswerkzeuge: Slack-Threads mit einer Zusammenfassung, die zurück ins Ticket gepostet wird, Design-Docs, auf die vom Ticket verlinkt wird, oder ein 15-minütiger Anruf mit Notizen, die in der Beschreibung festgehalten werden. Das Ticket ist die Landingpage für ein Stück Arbeit, nicht das Transkript jeder Konversation darüber.

Ein Backlog ist kein Parkplatz für Ideen — aber die meisten Teams behandeln es so. Jede Feature-Anfrage, jeder kleine Bug, jedes „nice to have" und jedes „das sollten wir irgendwann mal machen" bekommt ein Ticket, und dieses Ticket liegt monatelang unberührt herum. Der Backlog wächst. Niemand räumt auf. Irgendwann hat man 800 Tickets und keine Möglichkeit, die 30 wichtigen von den 770 unwichtigen zu unterscheiden.

Veraltete Backlogs verursachen echte Kosten. Entwickler verlieren Zeit beim Scrollen durch tote Tickets in der Planification. Neue Teammitglieder können nicht erkennen, welche Tickets aktuell sind und welche Fossilien von zwei Produkt-Pivots her. Suchen liefern Rauschen. Der Backlog wird zu einem schuldbeladenen Monument für Arbeit, die das Team nie erledigen wird — und jeder Blick darauf untergräbt das Vertrauen in den Planungsprozess.

Backlog-Hygiene ist eine Disziplin, keine einmalige Aufräumaktion. Eine gesunde Kadenz: Einmal im Monat jedes Ticket überprüfen, das älter als 90 Tage ist. Wenn es in drei Monaten nicht priorisiert wurde, ist es entweder nicht wichtig genug zum Erledigen oder nicht gut genug definiert zum Schätzen. Schließen. Wenn es wichtig ist, kommt es zurück — und wenn es das tut, kommt es mit frischem Kontext und aktuellen Prioritäten zurück.

Der Instinkt ist, Tickets „für alle Fälle" offen zu halten. Dieser Instinkt ist falsch. Ein geschlossenes Ticket ist nicht gelöscht — es ist durchsuchbar, verlinkbar und wieder öffenbar. Es zu schließen bedeutet nur, dass das Team ehrlich darüber ist, was tatsächlich im Umfang liegt. Ein 50-Ticket-Backlog, der echte Prioritäten widerspiegelt, ist unendlich nützlicher als ein 800-Ticket-Backlog, der jede Idee widerspiegelt, die jemals jemand hatte.