Es war ein Dienstagnachmittag. Ich hatte eine Aufgabe: Eine Filterkomponente für eine Produktliste sollte schneller werden. Ich wusste, wo das Problem ungefähr lag – also hab ich einfach angefangen.
Drei Stunden später hatte ich eine deutlich komplexere Komponente, einen refactorten State-Management-Layer und einen Haufen offener Fragen. War das Frontend-seitig gelöst oder hätte man das auch im Backend angehen können? Welche Filteroptionen sollten überhaupt gecacht werden? Und was war nochmal der Unterschied zur Mobilansicht?
Ich hatte gecoded, ohne das Problem wirklich zu verstehen. Das Ergebnis war entsprechend.
Ein Ticket ist kein Bürokratie-Akt
Wenn ich das Wort "Ticket" benutze, höre ich manchmal ein leises Stöhnen. Zu Recht – in vielen Teams bedeutet Ticket: Jira-Formular ausfüllen, drei Felder mit "N/A" befüllen, Deadline eintragen, Sprint zuweisen. Das hat mit dem, was ich meine, ungefähr so viel zu tun wie ein Arzttermin mit einem spontanen Spaziergang.
Ein Ticket in meinem Sinn ist einfach: eine kurze, klare Beschreibung eines Problems und des erwarteten Ergebnisses. Zwei Absätze. Manchmal drei Stichpunkte. Fertig.
Das Entscheidende ist nicht das Ticket selbst – sondern der Akt des Schreibens. Wer ein Problem aufschreiben muss, muss es erst durchdenken. Und das ist der eigentliche Gewinn.
Was in einem guten Ticket steckt
Ich halte es simpel. Drei Dinge reichen fast immer:
Ziel: Was soll nach diesem Change besser sein? Nicht "Filterkomponente optimieren" – sondern "Die Filterkomponente soll bei 500+ Einträgen ohne sichtbaren Lag reagieren."
Akzeptanzkriterien: Wann ist die Aufgabe erledigt? "Filter-Interaktion unter 100 ms, getestet auf einem Mid-Range-Android-Gerät." Kein Roman – aber konkret genug, dass ich abends weiß, ob ich fertig bin.
Out of Scope: Was ist explizit nicht Teil dieser Aufgabe? Das ist der unterschätzte Teil. Wenn ich aufschreibe "das Backend-Caching ist ein separates Ticket", bin ich drei Stunden später nicht plötzlich in einem anderen Problem versunken.
Mit AI ist das noch wichtiger
Wer Kontext-Engineering: Warum dein Prompt das kleinste Problem ist gelesen hat, kennt bereits das Prinzip: Die AI ist nur so gut wie der Kontext, den sie bekommt. Ein Ticket ist die Anwendung dieses Prinzips auf der Ebene des einzelnen Tasks.
Früher konnte ich mit einem vagen Plan loscoden und zumindest auf mein eigenes Urteil vertrauen. Ich kenne den Codebase, ich verstehe den Kontext, ich merke wenn ich abbiege.
Ein AI-Modell kann das nicht. Es hat keinen Kontext außer dem, den ich ihm gebe. Wenn ich schreibe "optimiere die Filterkomponente", bekomme ich Code, der irgendetwas optimiert – vielleicht genau das Richtige, vielleicht etwas das in Richtung Performance geht aber dabei Accessibility bricht, vielleicht eine generische Lösung die zum Projekt gar nicht passt.
Das Ticket zwingt mich, den Kontext herzustellen, bevor ich ihn weiterreiche. Danach kann ich der AI eine präzise Aufgabe geben – und bekomme ein präzises Ergebnis.
Saubere Commits als Nebeneffekt
Wer mit Tickets arbeitet, bekommt etwas geschenkt: eine lesbare Git-Historie.
Jeder Commit referenziert ein Ticket. fix: GBW-42 – filter response time under 100ms. Drei Monate später weiß ich sofort: Was war das Problem? Warum wurde das geändert? Was war der Scope?
Ohne Tickets sieht das anders aus. fix: performance. update filter. changes. Diese Commits haben mir in meiner Karriere schon viele graue Haare beschert – meistens meine eigenen.
Der Zusammenhang ist direkt: Wer das Problem klar beschrieben hat, kann die Lösung auch klar benennen. Und eine klar benannte Lösung ist ein guter Commit.
Der Nebeneffekt, der mich am meisten überrascht hat
Manchmal merke ich beim Schreiben des Tickets, dass ich es nicht schreiben kann.
Nicht weil das Problem zu komplex ist – sondern weil ich das Ziel nicht klar formulieren kann. Ich setze mich hin und merke: Ich weiß gar nicht genau, was ich will. Oder: Das Feature macht eigentlich keinen Sinn im aktuellen Zustand des Projekts. Oder: Das ist gar kein Problem des Frontends, sondern ein Problem des Datenmodells.
Das ist kein Versagen des Tickets. Das ist der Punkt. Ein Ticket zu schreiben kostet mich zehn Minuten. Drei Stunden in die falsche Richtung zu coden kostet mich – nun ja – drei Stunden. Plus die Zeit, es wieder rückgängig zu machen.
Das Ticket ist der günstigste Fehler, den ich machen kann. Denn wenn er passiert, passiert er auf Papier.
Wie ich es heute handhabe
Ich nutze YouTrack für mein eigenes Projekt – aber das Tool ist egal. Wichtig ist der Moment vor dem ersten Commit: Gibt es ein Ticket dafür?
Bei eigenen Projekten schreibe ich das Ticket selbst – oft in fünf Minuten. Bei Kundenprojekten ist es oft schon da, oder ich helfe beim Formulieren. Und wenn jemand sagt "das ist doch nur eine Kleinigkeit, muss das wirklich ein Ticket sein?"
Dann antworte ich: Gerade weil es eine Kleinigkeit ist, dauert das Ticket zwei Minuten. Und wenn es doch keine Kleinigkeit ist, hast du das gerade herausgefunden – ohne eine einzige Zeile Code geschrieben zu haben.
Im nächsten Post schaue ich auf die andere Seite derselben Frage: Was passiert, wenn man zwar ein Ticket hat, aber trotzdem zu früh anfängt – ohne die Architektur definiert zu haben?
Wer kein Ticket schreiben kann, hat sein Problem noch nicht verstanden. Und wer sein Problem nicht verstanden hat, sollte noch keinen Code schreiben – weder selbst, noch via AI.