Anatomie eines guten Tickets

Die meisten Tickets sind schlecht. Es sind vage Titel – „Login-Bug beheben", „Dashboard aktualisieren", „Backend-Arbeit" – ohne Beschreibung, ohne Akzeptanzkriterien und ohne Kontext für irgendjemanden außer der Person, die sie geschrieben hat. Diese Tickets erzeugen die Illusion von Nachverfolgung, während sie tatsächlich nichts Nützliches nachverfolgen.

Ein gutes Ticket hat drei Teile:

• Titel als Ergebnis. Der Titel beschreibt, was wahr sein wird, wenn die Arbeit erledigt ist, nicht welche Aktivität stattfinden wird. „Benutzer können Passwort per E-Mail zurücksetzen" ist ein Ergebnis. „An Passwort-Sachen arbeiten" ist eine Aktivität. Der Unterschied ist wichtig, weil ergebnisorientierte Titel testbar sind – man kann sich die fertige Arbeit ansehen und fragen „ist das wahr?"
• Beschreibung als Warum. Die Beschreibung erklärt, warum diese Arbeit wichtig ist, und liefert genug Kontext, damit jemand Unvertrautes die Entscheidung verstehen kann. Kein Roman – zwei bis drei Sätze, die „warum jetzt?" und „welche Auswirkung hat das auf den Benutzer?" beantworten.
• Akzeptanzkriterien als Was. Eine kurze Liste konkreter, testbarer Bedingungen, die „fertig" definieren. Nicht „es sollte gut funktionieren" – sondern „der Endpunkt gibt eine 200 mit einem gültigen Token zurück, eine 401 bei abgelaufenen Anmeldedaten und eine 429 nach 5 fehlgeschlagenen Versuchen in 60 Sekunden."

Der Test für ein gutes Ticket ist der Aufnahmetest: Könnte ein Entwickler, der nicht in dem Meeting war, in dem dies besprochen wurde, es aufnehmen und liefern, ohne klärende Fragen zu stellen? Wenn die Antwort nein ist, ist das Ticket nicht fertig – es ist ein Platzhalter.

Akzeptanzkriterien sind der am häufigsten übersprungene Teil eines Tickets und der teuerste, den man überspringen kann. Ohne sie ist „fertig" das, was der Entwickler, der daran gearbeitet hat, für richtig hält – was möglicherweise nicht dem entspricht, was der Product Manager erwartet hat, wogegen QA testen wird oder was der Kunde tatsächlich braucht.

Gute Akzeptanzkriterien sind konkret und testbar. „Die Suche sollte schnell sein" ist kein Akzeptanzkriterium – es ist eine Hoffnung. „Suchergebnisse werden in unter 200 ms für Abfragen bis zu 1.000 Datensätzen zurückgegeben" ist testbar. „Das Formular sollte Fehler elegant behandeln" ist vage. „Das Formular zeigt eine rote Inline-Fehlermeldung an, wenn das E-Mail-Feld leer ist und der Benutzer auf Absenden klickt" ist spezifisch genug, um danach zu entwickeln und zu verifizieren.

Akzeptanzkriterien sollten vereinbart werden, bevor die Arbeit beginnt, nicht danach geschrieben werden. Wenn sich ein Entwickler und ein Product Manager vor der ersten Codezeile auf Kriterien einigen, einigen sie sich auf den Umfang. Ohne diese Abstimmung baut der Entwickler, was er verstanden hat, der PM erwartete etwas anderes, und das Ticket kommt zurück – was beiden Zeit kostet und das Vertrauen untergräbt. Akzeptanzkriterien im Voraus zu schreiben dauert 10 Minuten. Eine missverstandene Funktion nachzuarbeiten dauert Tage.

Die Beschreibung ist die Quelle der Wahrheit. Kommentare sind die Unterhaltung darüber. Sie zu vermischen führt dazu, dass Tickets unleserlich werden.

Die Beschreibung sollte alles enthalten, was jemand braucht, um die Arbeit zu verstehen: den Kontext, die Anforderungen, die Akzeptanzkriterien und alle relevanten Links. Sie wird einmal geschrieben (und aktualisiert, wenn sich der Umfang ändert). Es ist der Teil, den man zuerst liest, wenn man ein Ticket aufnimmt, und er sollte die Fragen beantworten, ohne dass man durch 47 Kommentare scrollen muss.

Kommentare sind für Diskussionen, die während der Arbeit stattfinden: klärende Fragen, Umfangsverhandlungen, Statusaktualisierungen, Review-Feedback. Kommentare sind nur zum Anhängen und chronologisch – sie erfassen die Unterhaltung, nicht die Schlussfolgerung. Wenn ein Kommentar-Thread eine Frage klärt, die die Anforderungen ändert, geht die Antwort zurück in die Beschreibung. Die Beschreibung wird bearbeitet; der Kommentar bleibt als Prüfpfad, wie die Entscheidung getroffen wurde.

Teams, die alles in Kommentare werfen, enden mit Tickets, bei denen die tatsächlichen Anforderungen in Kommentar #23 vergraben sind, eingeklemmt zwischen einem Statusupdate und einer Emoji-Reaktion. Der Entwickler, der das Ticket aufnimmt, muss den gesamten Thread lesen, um den aktuellen Stand zu rekonstruieren. Das ist keine Koordination – das ist Archäologie.