Was gehört in ein Ticket? Drei Felder reichen

Die meisten Ticket (seien es Stories, Tasks oder Bugs) sind zu lang. Zwölf Felder, drei Pflicht-Dropdowns, ein Abschnitt „Technische Details“, den keiner liest. Heraus kommen leere Felder, halbherzig ausgefüllte Dropdowns und Arbeit, die lieber gleich im Chat landet, weil das schneller geht als jedes Formular.

Mein Tipp: Ein gutes Ticket hat drei Felder. Ein Bug hat drei andere. Alles Weitere klärt ihr im Gespräch und schreibt das Ergebnis dazu.

Das gilt für Jira genauso wie für GitHub, GitLab, Trello oder OpenProject. Und es ist egal, ob ihr das Ding Story, Task oder Aufgabe nennt.

Jedes Ticket: Titel, Warum, Acceptance Criteria

Titel: Auf dem Board, in der Suche und in jeder Benachrichtigung siehst du nur den Titel, also muss er verständlich sein, ohne dass jemand das Ticket öffnet. „Benutzerprofil optimieren“ ist kein Titel, das ist eine Stunde Diskussion im Planning. „Profilbild per Drag-and-drop hochladen“ ist einer. Steht ein „und“ drin, sind es zwei Tickets.

Warum: Ohne Grund kann niemand eine bessere Lösung vorschlagen oder sagen, dass sich das Ganze nicht lohnt. Ob du das als User Story schreibst („Als … möchte ich … damit …“) oder als normalen Satz, ist Geschmack (Ich mag eine klare Info lieber als die "User Story Formulierung"). Dass der Grund drinsteht, nicht. Dazu gehört die Herkunft: wer, welcher Kanal, wann. Bei einer Mail auch der Betreff, dann findet man sie im Postfach wieder. Dann gehen Rückfragen an die richtige Person, und ein einzelner Kundenwunsch lässt sich von drei Support-Fällen unterscheiden.

Acceptance Criteria. Woran merken alle, dass es fertig ist? Jedes Kriterium beschreibt ein Ergebnis, das man prüfen kann, zum Beispiel „Mail kommt innerhalb von 30 Sekunden an“. Wie das Team das baut, ist seine Sache. „Schnell“ ist kein Kriterium, „unter zwei Sekunden“ schon. Mehr als drei sind ein Warnsignal: Dann ist das Ticket zu groß und gehört geschnitten. Und was in eurer Definition of Done steht, musst du nicht in jedes Ticket abschreiben.

Den Rest schreibst du nur, wenn es ihn gibt:

Ein leerer Abschnitt „Offene Fragen: keine“ ist genau der Ballast, den wir loswerden wollen. Lass ihn einfach weg.

Bugs: Steps to Reproduce, Expected/Actual, Environment

Bei einem Bug bleiben Titel und Warum. Statt Acceptance Criteria kommen diese drei:

Die Steps sind das Wichtigste, denn was sich nicht nachstellen lässt, lässt sich auch mit viel Erfahrung kaum fixen. Expected ist das Feld, das am häufigsten fehlt, und gleichzeitig das, an dem sich oft zeigt, dass es gar kein Bug ist, sondern ein Wunsch. Dann wird daraus ein normales Ticket. Und die Environment erspart euch das klassische „Works on my machine“.

Screenshots helfen auch hier, Fehlermeldungen gehören aber zusätzlich als Text ins Ticket. Text kann man kopieren und durchsuchen.

Was das Tool schon kann

Assignee, Status, Related Links. Dafür hat jedes Tool eigene Felder, die beim Anlegen niemand ausfüllen muss. Zwei Regeln reichen: Es gibt genau eine zuständige Person, und der Status lebt auf dem Board, weil er überall sonst sofort veraltet. „In Arbeit seit Dienstag“ in der Beschreibung ist am Mittwoch schon falsch.

Jedes weitere Feld braucht einen Grund und jemanden, der es pflegt. Jeder weitere Status auch. Ein neuer Status lohnt sich nur, wenn sich dadurch ändert, wer als Nächstes handeln muss.

Chat, Mail, Telefon: rein als Kommentar

Chat ist gut für Rückfragen und gemeinsames Debuggen. Das Problem beginnt erst, wenn das Ergebnis dort bleibt und drei Wochen später niemand mehr weiß, wer was zugesagt hat. Was im Chat entschieden wird, haben die Abwesenden nie gelesen. Was per Mail kam, kennt genau eine Person.

Deshalb: Wenn dein Tool Kommentare kann, nutze sie. Jede Info zur Aufgabe kommt als Kommentar ins Ticket, egal ob aus Slack, Teams, Mail, Telefonat oder Daily. Mit Quelle.

Teams, Anna, 10.10.: „Brauchen wir bis KW 44 für Kunde X.“

Den wichtigen Satz zitieren, nicht nur verlinken, denn Chat-Links verfallen. Ändert sich dadurch etwas Grundsätzliches, wird die Beschreibung oben angepasst. Wer neu dazukommt, liest die Beschreibung und nicht 40 Kommentare.

Was nie reingehört

Lösungsvorgaben wie „Button blau, 3 px Radius“, wenn das eigentliche Problem ist, dass Kunden den Button nicht finden. Passwörter, Tokens und Kundendaten, weil Tickets breit gelesen werden und lange gespeichert bleiben. Und Schuld. Schreib über das System: „Deploy-Skript prüft die Umgebung nicht“. Der Satz „Max hat auf Prod deployt“ hilft niemandem.

Für Kunden: ein eigenes PDF

Viele Tickets sind schon schlecht, bevor das Team sie sieht: Der Kunde schreibt „Upload geht nicht“, und dann beginnen drei Tage Ping-Pong per Mail. Gib Kunden und Fachbereich deshalb ein eigenes PDF. Kurz, ohne Fachwörter, mit einem halben Satz Begründung pro Frage. „Ohne die Schritte finden wir den Fehler nicht“ überzeugt mehr als ein Pflichtfeld.

Zum Download

Ticket-Leitfaden fürs Team (PDF): eine Seite mit allen Feldern, der Kommentar-Regel und dem, was nie reingehört. Zum Ausdrucken oder fürs Wiki.

Kunden-Handout „Das brauchen wir von dir“ (PDF): eine Seite für Kunden und Fachbereich, mit Begründung und Beispiel zu jeder Frage.

Fang mit Streichen an

Leg eure aktuelle Vorlage neben diese Liste. Jedes Pflichtfeld, das in den letzten drei Monaten niemand gelesen oder für eine Entscheidung gebraucht hat, fliegt raus. Dann schaut nach vier Wochen, ob die Rückfragen im Refinement weniger geworden sind.

Und wenn deine Vorlage mit noch weniger auskommt: Zeig sie mir.

Feedback oder Widerspruch? Schreib mir auf Mastodon an @nobsagile oder per Mail an nobsagile@gmail.com.