Darf man an deinem D&D-Tisch „Stopp“ sagen?Nur weil niemand widerspricht, fühlen sich noch lange nicht alle wohl.In Session Zero klärt ihr Regeln, Grenzen un...

Darf man an deinem D&D-Tisch „Stopp“ sagen?Nur weil niemand widerspricht, fühlen sich noch lange nicht alle wohl.In Session Zero klärt ihr Regeln, Grenzen un...

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 **Feld** | **Was rein gehört** | **Beispiel** ---|---|--- **Titel** | Was soll passieren, konkret, eine Zeile | Gutschein im Warenkorb entfernen können **Warum** | Welches Problem, für wen, woher die Info kommt | Kunden brechen ab, wenn sie einen Gutschein loswerden wollen. Quelle: Mail von Frau Berg, 2.10., Betreff „Kunden brechen ab“ **Acceptance Criteria** | Ein bis drei prüfbare Punkte | Gutschein mit einem Klick entfernbar. Preis aktualisiert sich sofort. **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: **Wenn vorhanden** | **Warum** | **Beispiel** ---|---|--- **Screenshots** | Ein Bild zeigt in einer Sekunde, welche Stelle gemeint ist | Warenkorb mit markiertem Gutscheinfeld **Links** | Niemand muss suchen, wo das Problem wohnt. Am besten Frontend und Backend | Link zur Seite im Shop, Link zur Bestellung im Admin **Bestehende Doku** | Das Wissen gibt es schon, es muss nur auffindbar sein | Konzeptseite „Gutscheinlogik“ im Wiki **Out of Scope** | Grenzt ab, bevor das Ticket wächst | Mehrere Gutscheine gleichzeitig brauchen wir nicht **Offene Fragen** | Sichtbar im Ticket statt im Kopf einer Person | Gilt das auch für Firmenkunden? 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: Feld | Was rein gehört | Beispiel ---|---|--- **Steps to Reproduce** | Was hast du gemacht, nummeriert | 1. Als Redakteur einloggen 2. Bild ins Textfeld ziehen 3. Speichern **Expected / Actual** | Zwei Zeilen, Fehlermeldung als Text | Expected: Bild erscheint im Text. Actual: Seite lädt neu, Text ist weg, „Error 500“. **Environment** | System, Version, Browser | Prod, Build 4.3, Chrome auf Windows 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. **Anliegen** | **Was wir von dir brauchen** ---|--- **Etwas Neues** | Worum geht es? Welches Problem hast du heute? Woran merkst du, dass es fertig ist? **Eine Änderung** | Was genau? Wo genau? Ab wann? Neuen Text bitte fertig zum Kopieren. **Ein Fehler** | Was hast du gemacht? Was hast du erwartet? Was ist passiert? Wo, also welche Seite und welcher Browser? ## 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.