Gute Tickets sparen dir eine Menge Zeit und damit eine Menge Geld! Egal ob du ein wendiges Startup bist, das einen Berater durch den IT-Dschungel braucht, oder ein großer internationaler Konzern.
Und trotzdem sehe ich jeden Tag schlechte Tickets. Tickets, die drei Rückfragen brauchen, bevor eine Entwicklerin überhaupt anfangen kann. Tickets, die tagelang zwischen Stakeholder und Entwicklung hin- und herwandern. Tickets, die so vage sind, dass drei Entwickler drei völlig verschiedene Lösungen bauen würden.
Das ändern wir.
Was macht ein schlechtes Ticket aus?
Bevor wir über gute Tickets reden, so sieht ein schlechtes aus:
„Der Login ist kaputt. Bitte reparieren."
Das war's. Das ist das ganze Ticket. Wo ist der Login kaputt? In welchem Browser? Für welche Nutzer? Seit wann? Und was heißt „kaputt" – reagiert der Button nicht, bekommt der Nutzer einen Fehler, oder leitet die Seite einfach irgendwohin falsch weiter?
Eine Entwicklerin, die das liest, hat zwei Möglichkeiten: raten oder nachfragen. Beides kostet Zeit. Eines davon liefert die falsche Lösung aus.
Der Aufbau eines guten Tickets
1. Ein klarer, konkreter Titel
Der Titel sollte dir sagen, was passieren muss, ohne dass du das Ticket überhaupt öffnest. Vergleich mal:
- Schlecht: „Login reparieren"
- Gut: „Login-Button unter iOS 16 (Safari) reagiert nicht auf Tippen"
Ein guter Titel ist konkret genug, dass du ihn in sechs Monaten suchen kannst und sofort weißt, worum es ging.
2. Beschreibung: das Was, nicht das Wie
Beschreib das Problem oder die Anforderung – nicht die Lösung. Entwickler werden dafür bezahlt, das Wie herauszufinden. Deine Aufgabe ist, das Was klar zu erklären.
Bei einem Bug: beschreib, was passiert, was du erwartet hast, und die genauen Schritte zum Reproduzieren. Bei einem Feature: beschreib, was der Nutzer können soll, aus Sicht des Nutzers.
Ein Screenshot ist tausend Worte wert. Eine Bildschirmaufnahme ist tausend Screenshots wert. Häng bei einem Bug immer einen visuellen Beleg an – das halbiert die Debugging-Zeit.
3. Akzeptanzkriterien
Das ist der am meisten unterschätzte Teil jedes Tickets. Akzeptanzkriterien beantworten eine einfache Frage: Woran erkennen wir, dass es fertig ist?
Ohne sie heißt „fertig" für die Entwicklerin, die QA und den Stakeholder jeweils etwas anderes. Mit ihnen sind alle ab Tag eins auf demselben Stand. Schreib sie als einfache Checkliste:
- Nutzer kann sich mit E-Mail und Passwort einloggen
- Fehlgeschlagene Logins zeigen eine klare Fehlermeldung
- Nach 5 Fehlversuchen wird das Konto vorübergehend gesperrt
- Funktioniert in Chrome, Firefox und Safari (Desktop und mobil)
Ein Ticket ohne Akzeptanzkriterien ist wie eine Pizza zu bestellen, ohne den Belag zu nennen. Du kriegst etwas – nur wahrscheinlich nicht das, was du wolltest.
4. Priorität und Kontext
Nicht jedes Ticket ist ein Großbrand. Sag der Entwicklerin, ob das heute raus muss oder bis zum nächsten Sprint warten kann. Und erklär, warum es wichtig ist – was ist die Auswirkung fürs Geschäft? Dieser Kontext hilft Entwicklern, klügere Entscheidungen zu treffen, wenn sie mitten in der Umsetzung auf unerwartete Sonderfälle stoßen.
5. Technische Details (falls du sie hast)
Wenn du weißt, welches System, welcher Endpunkt, welche Komponente oder welche Seite betroffen ist – sag es. Lass die Entwicklerin nicht Archäologin spielen. Du hast passende Logs, Fehlermeldungen oder Network-Requests aus der Browser-Konsole? Häng sie an. Je mehr Kontext, desto schneller die Lösung.
Die goldene Regel
Bevor du ein Ticket abschickst, frag dich: Könnte eine Entwicklerin damit sofort anfangen, ohne mir eine einzige Frage zu stellen?
Wenn die Antwort nein ist, ist das Ticket noch nicht fertig.
Die Kosten eines schlechten Tickets sind nicht nur das Hin und Her. Es sind der Kontextwechsel, die falsche Umsetzung, die Nacharbeit, die gerissene Deadline. Schreib es beim ersten Mal richtig.
Ein gutes Ticket zu schreiben ist ein Akt des Respekts vor der Zeit der Entwicklerin. Die 10 Minuten, die du in ein ordentliches Ticket investierst, sparen Stunden an Kommunikation – und verhindern, dass komplett das Falsche gebaut wird.