Ticket Smells: So erkennst du einen schlechten Schnitt, bevor du das Ticket ziehst

Jedes Team kennt dieses eine Ticket. Es las sich wie ein Zwei-Punkte-Ticket. "Ein Feld zum Export hinzufügen." Jemand zog es am Montagmorgen, voller Zuversicht. Bis Donnerstag hatte es eine Datenbankmigration verschlungen, eine Übersetzungsrunde und eine Diskussion darüber, wie man alte Datensätze nachträglich befüllt. Das Sprint Review war unangenehm.

Dieses Ticket hatte kein Pech. Es war schon faul, als es aufs Board kam, und die Fäulnis war sichtbar, für jeden, der wusste, wonach er schnuppern muss.

Bei Code machst du das längst. Eine Funktion mit fünf Boolean-Parametern, eine utils.ts, die inzwischen viertausend Zeilen hat, ein Kommentar mit "nicht anfassen": Du spürst, dass etwas faul ist, bevor du es beweisen kannst. Dieses Gespür hat einen Namen. Kent Beck prägte den Begriff "Code Smell" und Martin Fowler machte ihn bekannt: ein Oberflächensignal für ein tieferes Problem. Tickets haben ebenfalls Gerüche. Der Unterschied ist nur, dass dir niemand beigebracht hat, sie wahrzunehmen. Also explodieren sie am Sprintende, statt am Anfang aufzufallen.

Das hier ist ein Feldführer zu den vier Ticket Smells, die Teams am meisten kosten: warum jeder davon wehtut (die Forschung ist klarer, als du denkst), woran du ihn auf dem Board erkennst und was die billigste Gegenmaßnahme ist. Das Ziel ist nicht das perfekte Ticket. Es ist der Instinkt, damit ein schlechter Schnitt dir die Nase rümpfen lässt, bevor du ihn je in "In Arbeit" ziehst.

Er zeigt dir die Spitze. Die Masse liegt unter Wasser.

Der Eisberg sieht klein aus und ist es nicht. "Nur ein Feld hinzufügen." "Den Report einfach migrieren." An der Oberfläche ist es ein Eingabefeld oder ein mechanischer Handgriff. Darunter liegen eine Migration, eine Änderung am API-Vertrag, eine i18n-Runde und ein Backfill, den niemand erwähnt hat.

Das ist keine Nachlässigkeit. Es ist Verdrahtung im Kopf. Der Planning Fallacy ist die belegte menschliche Neigung, eigene Aufgaben zu unterschätzen, selbst wenn wir uns erinnern, dass die letzte länger dauerte. In einer Studie schätzten Studierende ihre eigene Abschlussarbeit auf durchschnittlich 33,9 Tage; tatsächlich waren es im Schnitt 55,5 Tage, schlimmer als ihre eigene pessimistischste Vorhersage.¹ Und Schätzungen sind genau dann am weitesten daneben, wenn du am wenigsten weißt. Steve McConnells Cone of Uncertainty beziffert die früheste Schätzung auf bis zum Vierfachen zu hoch oder zu niedrig, eine Spanne von Faktor sechzehn, und sie wird nur enger, wenn du Unbekanntes auflöst, nicht weil Zeit vergeht.²

Wer das Ticket geschrieben hat, ist am schlechtesten in der Lage, den Eisberg zu sehen, wegen des Curse of Knowledge: Wer ein System einmal kennt, bei dem werden die schweren Teile zum Reflex und sehen nicht mehr nach Arbeit aus. (Dazu später mehr. Das ist ein eigenes Biest.)

Das Anzeichen

• Verharmlosende Verben: "nur", "einfach", "schnell", "bloß". Je kleiner das Wort, desto größer der Eisberg.
• Vage Tätigkeitsverben ohne Objekt: "aktualisieren", "behandeln", "unterstützen", "integrieren", ohne dass jemand sagt, wie "fertig" aussieht.
• Dünne oder fehlende Akzeptanzkriterien. Nichts zu Sonderfällen, Migration oder Bestandsdaten.
• Eine breite Streuung in der Schätzung. Wenn einer 3 sagt und ein anderer 13, ist diese Lücke kein Rauschen, das man wegmittelt.

Die Gegenmaßnahme

Wenn eine Story zu groß ist, um sie zuversichtlich zu schätzen, ist das kein Grund, fester zu raten. Bill Wake, der die INVEST-Checkliste für gute Stories geprägt hat, merkt an: "Das würde länger als einen Monat dauern" trägt fast immer eine versteckte zweite Hälfte in sich: "weil ich nicht verstehe, was alles dazugehört."⁴ Selbstbewusste Größe und geringes Verständnis reisen gemeinsam.

Zwei Züge. Teile es, bevor du dich festlegst. Oder, wenn die Unsicherheit echt ist, mach einen Spike: eine zeitlich begrenzte Untersuchung, deren einzige Aufgabe es ist, genug Wissen zu kaufen, um schätzen oder teilen zu können. Halte Spikes selten; Mike Cohn warnt, dass ihr Übermaß nur deine Time to Value verlängert.⁵

Zwei Tickets auf dem Board, in Wirklichkeit ein Stück Arbeit.

Jemand hat das Feature geteilt, also zeigt das Board zwei Karten: "Login-API bauen" und "Login-Screen bauen." Das fühlt sich nach Fortschritt an. Es ist eine Illusion. Der Screen hat nichts, was er aufrufen könnte. Die API hat nichts vorzuzeigen. Keiner von beiden lässt sich allein demonstrieren, und die Integration, dort wo die Bugs wirklich wohnen, versteckt sich in einem dritten Schritt, den niemand geticketet hat.

Das ist horizontales Schneiden: Arbeit nach technischer Schicht zerlegen (Backend, Frontend, Datenbank) statt nach Wert. Humanizing Work wird hier deutlich. Nach Architekturschicht zu teilen "mag Small erfüllen, scheitert aber an Independent und Valuable."⁶ Eine Schicht ist kein Schnitt. Eine Datenbanktabelle ohne Screen liefert nichts, was ein Stakeholder sehen kann. Genau deshalb stellte Wake Independent in INVEST an die erste Stelle und nannte Überlappung "die schmerzhafteste Form der Abhängigkeit."⁴

Die Kosten zahlt der Flow. Gekoppelte Tickets können sich nicht aus eigener Kraft bewegen. Sie warten aufeinander, sie erzwingen Übergaben und schieben das Integrationsrisiko ans Sprintende, wo keine Zeit mehr ist, es aufzufangen.⁷

Das Anzeichen

• Die beiden Karten teilen sich einen Branch oder einen einzigen Pull Request. Zwei IDs, ein Merge.
• Keine der beiden lässt sich allein demonstrieren.
• Eine dauerhafte "blockiert durch"-Verknüpfung zwischen ihnen, besonders eine Kette.
• Sie werden immer zusammen geschätzt und immer derselben Person im selben Sprint zugewiesen.
• Eine Karte ist nach einer Schicht benannt, nicht nach einem Ergebnis: "Backend für X", "API für X", "UI für X".

Die Gegenmaßnahme

Schneide vertikal. Ersetze "API bauen" plus "Screen bauen" durch eine dünne Story, die von oben nach unten reicht: "Eine Nutzerin kann sich mit gültiger E-Mail und Passwort einloggen", UI, Service und Speicherung in einem demonstrierbaren Inkrement. Falls das zu groß ist, schneide weiter vertikal, nicht horizontal: zuerst der Happy Path, dann die Behandlung falscher Passwörter, dann die Sperre. Jeder Schnitt ist Full Stack und lieferbar.

Wenn zwei Teams wirklich parallel arbeiten müssen, entkoppele über einen Vertrag zuerst: Einigt euch vorab auf die Form der API, damit das Frontend gegen einen Stub baut, während das Backend das Echte baut, ganz ohne hartes "blockiert durch" dazwischen. Oder baue ein Walking Skeleton, einen winzigen End-to-End-Pfad, der die echten Komponenten verbindet, und verdicke dann jeden Schnitt.⁸

Geschrieben von jemandem, der das ganze Lied hört. Gelesen von jemandem, der nur das Klopfen bekommt.

1990 führte eine Stanford-Forscherin namens Elizabeth Newton ein Experiment durch. Eine Gruppe klopfte den Rhythmus eines bekannten Lieds auf einen Tisch. Die andere Gruppe sollte es erraten. Die Klopfer sagten voraus, die Zuhörer würden es etwa zur Hälfte erkennen. Tatsächlich erkannten die Zuhörer 3 von 120 Liedern, zweieinhalb Prozent. Die Klopfer hörten die volle Melodie in ihrem Kopf. Die Zuhörer hörten zusammenhanglose Schläge.⁹

Das ist der Curse of Knowledge, ein 1989 in einem ökonomischen Aufsatz benannter und von Chip und Dan Heath bekannt gemachter Denkfehler: Sobald du etwas weißt, kannst du nicht mehr rekonstruieren, wie sich Nichtwissen anfühlte.¹⁰ Das verfluchte Ticket ist reines Klopfen. Es nennt eine Lösung ("eine Redis-TTL am Profile-Resolver ergänzen, bei PROFILE_UPDATED invalidieren") und löscht das Problem. Wer es zieht, setzt es wörtlich um, liefert aus und erfährt im Review, dass das eigentliche Problem veraltete Avatare nach dem Upload waren, was eine feste TTL noch verschlimmert.

Das "damit" trägt den Grund eines Tickets, und es fällt als Erstes weg. Mike Cohn nennt die damit-Klausel oft den wichtigsten Teil einer Story, denn zu wissen, warum jemand etwas will, offenbart häufig einen besseren Weg, es zu liefern.¹¹ Ein Ticket, das sagt, was zu bauen ist, aber nie warum, reicht dir eine Lösung mit abgerissenem Problem.

Hier dasselbe Ticket, einmal verflucht und einmal geheilt.

text
TITEL: Redis-TTL am User-Profile-Resolver ergaenzen
Setze eine TTL von 300s auf den Cache-Key des Profile-Resolvers. Nutze die
bestehende cacheWrap-HOF. Invalidiere bei PROFILE_UPDATED.

Wer es zieht, weiß nicht warum (Performance? Kosten? ein Staleness-Bug?), wie "korrekt" aussieht, oder ob 300s eine Anforderung oder eine Schätzung sind. Nun die geheilte Fassung:

text
TITEL: Profilseiten laden unter Last langsam; Profil-Read cachen
Als eingeloggte Nutzerin moechte ich, dass mein Profil schnell laedt, damit
ich bei viel Traffic nicht auf einen Spinner starre.

Kontext: Profil-Reads treffen bei jeder Anfrage die DB und sind unser
langsamster p95-Endpunkt zur Spitzenzeit. Die Daten aendern sich selten,
ausser direkt nachdem die Nutzerin sie bearbeitet hat.

Akzeptanzkriterien:
- Gegeben ein Profil wurde kuerzlich gelesen, wenn es erneut angefragt wird,
  dann kommt es aus dem Cache und p95 faellt unter 150 ms im Last-Test.
- Gegeben eine Nutzerin aktualisiert ihr Profil, wenn der naechste Read
  erfolgt, dann zeigt die Antwort die Aenderung sofort (keine alten Daten).
- Gegeben ein Cache-Miss oder Ausfall, wenn ein Profil angefragt wird, dann
  laedt es weiterhin aus der DB (kein Fehler).

Hinweis: Redis/TTL ist ein moeglicher Ansatz. Waehle, was die Kriterien erfuellt.

Das Anzeichen

• Kein "damit", kein genannter Wert. Die Karte nennt einen Bau, nie einen Grund.
• Lösung diktiert, Problem abwesend: "Redis-TTL ergänzen", "den Selector memoizen", ohne ein nutzerseitiges Symptom.
• Keine Akzeptanzkriterien oder vage: "schnell", "sauber", "benutzerfreundlich", nichts, was eine Testerin prüfen könnte.
• Dichter Insider-Jargon: interne Codenamen, Event-Namen, Dateiverweise, ohne Erklärung.
• Ein Autor, null Diskussion. Keine Fragen im Thread, keine Testperspektive. Das mentale Modell verließ nie einen Kopf.

Die Gegenmaßnahme

Mach das Implizite explizit, bevor das Ticket bereit ist, und tu es als Gespräch, nicht als Dokumentationspflicht. Zwei billige Rituale tragen den Großteil. Three Amigos: eine Produktperson, eine Entwicklerin und eine Testerin schauen gemeinsam auf die Story, eine fragt nach dem Problem, eine fragt nach dem Bauen, eine fragt, was kaputtgehen kann.¹² Example Mapping, Matt Wynnes 25-Minuten-Technik: vier Kartenfarben, die Story, ihre Regeln, konkrete Beispiele und die offenen Fragen, die noch niemand beantworten kann.¹³ Das Kartenmuster ist sein eigener Smell-Test. Ein Stapel roter Fragekarten heißt, zu viel steckt noch in einem Kopf, und wenn ihr die Story nicht in etwa 25 Minuten mappen könnt, ist sie zu groß oder zu vage, um zu starten.

Zu groß, um sich zu bewegen. Er liegt wochenlang auf dem Board, und das Board zeigt nichts, weil es nichts Kleineres als das Ganze zum Fertigstellen gibt.

"User-Account-Verwaltung bauen" kommt in den Sprint. Drei Wochen später ist es noch "In Arbeit". Nicht weil niemand arbeitet, sondern weil das Ticket ein unteilbarer Klumpen ist, also produziert es keine Fertigstellung, keinen Durchsatz, keine sichtbare Bewegung, bis es vollständig fertig ist. Derweil klettert sein Alter still über alles hinaus, was das Team sonst ausliefert.

Große Batches sind langsame Batches. Kleinere Stücke werden schneller fertig, geben früher Feedback und tragen weniger Risiko; das ist der am besten untersuchte Hebel in Donald Reinertsens Arbeit zum Produktfluss. Little's Law macht die Falle exakt: Die mittlere Cycle Time ist gleich Work in Progress geteilt durch Durchsatz, also je mehr du gleichzeitig offen hältst, desto länger braucht jedes einzelne Stück.¹⁴

Die Kennzahl, die einen Felsbrocken früh erwischt, ist das Work Item Age: wie lange ein unfertiges Stück schon in Arbeit ist. Cycle Time und Durchsatz hinken hinterher; sie beschreiben nur fertige Arbeit. Das Alter geht voraus; es warnt dich, während das Stück noch feststeckt.¹⁵ Trag es gegen die Historie deines Teams auf, und ein Felsbrocken überquert die 85.-Perzentil-Linie lange bevor er offiziell zu spät ist.¹⁶

Das Anzeichen

• Seit mehreren Tagen kein Statuswechsel. Das simpelste Stillstandssignal überhaupt.
• Die Story ist über zwei oder mehr Sprints gerollt.
• Eine Schätzung größer als der halbe Sprint.
• Viele Subtasks, alle noch offen. Die Arbeit ist zersplittert, aber nichts wird fertig.
• Ein dauerhaftes "In Arbeit". Das Alter zählt auch Leerlauf- und Blockierzeit, also altert ein Ticket, das niemand anfasst, trotzdem.

Die Gegenmaßnahme

Bring es auf die richtige Größe, bevor du dich festlegst. Eine gängige Faustregel: Wenn eine Story länger als ein paar Tage dauert, teile sie. Geschnitten in "Profil ansehen", "E-Mail ändern", "Passwort ändern" und "Account löschen", erreicht dieselbe Arbeit alle ein bis zwei Tage ein Done. Das Board bewegt sich, der Durchsatz ist echt, und wenn ein Schnitt blockiert (etwa "Account löschen" wartet auf das Rechtliche), altert nur dieses kleine Stück, während der Rest ausliefert.

Tritt einen Schritt zurück, und die Smells reimen sich. Der Eisberg ist ein Schnitt, der seine Größe verbarg. Die Zwillinge sind ein Schnitt entlang der falschen Achse. Der Klopfer ist ein Schnitt ohne seinen Grund. Der Felsbrocken ist ein Schnitt, der nie gemacht wurde. Jeder davon ist ein Versagen beim Schneiden, und gut zu schneiden ist eine erlernbare Fähigkeit, kein Talent.

Beginne mit INVEST (Bill Wake, 2003): Eine gute Story ist Independent, Negotiable, Valuable, Estimable, Small und Testable.⁴ Es ist die Checkliste hinter jedem Anzeichen oben. Independent tötet die Zwillinge. Estimable und Small töten den Eisberg und den Felsbrocken. Valuable und Testable töten den Klopfer.

Die wichtigste Gewohnheit ist, vertikal zu schneiden, nicht horizontal. Eine Story sollte ein dünner Schnitt durch den ganzen Kuchen sein (UI, Logik, Daten), der etwas Vorzeigbares liefert, nicht eine einzelne Schicht davon.¹⁷ Wakes ursprüngliches Bild von 2003 sagt es immer noch am besten: Eine Story ist ein Kuchen, und den Kunden interessiert ein Stück, nicht die Datenbankschicht für sich allein.

Wenn sich eine Story dem Teilen widersetzt, helfen zwei benannte Werkzeugkästen. Mike Cohns SPIDR gibt fünf Achsen zum Schneiden: Spike, Paths, Interfaces, Data, Rules.¹⁸ Richard Lawrences Humanizing-Work-Leitfaden ergänzt einen Ablauf und neun Muster, mit zwei Faustregeln, die man sich merken sollte: Bevorzuge den Schnitt, der dich den geringwertigen Teil weglassen oder verschieben lässt, und bevorzuge Schnitte, die ungefähr gleich groß herauskommen.⁶

Ein durchgespieltes Beispiel. Das Davor ist horizontal und riesig:

text
- Die Payments-Datenbank bauen
- Den Payment-Service bauen
- Die Checkout-UI bauen

Nichts liefert aus, bis alle drei stehen, und die ersten beiden sind reine Verrohrung ohne eigenen Wert. Das Danach ist vertikal und dünn, mit SPIDR Paths und Rules:

text
- Eine Nutzerin kann einen Artikel per Kreditkarte zahlen, Happy Path, End to End
- PayPal als zweiten Zahlweg ergaenzen
- Zahlung ablehnen, wenn das Rechnungsland nicht unterstuetzt wird
- Einen Rabattcode an der Kasse pruefen

Jede Zeile ist lieferbar, vorzeigbar und für sich wertvoll. Läuft der Sprint knapp, lässt du den Rabattcode weg und hast trotzdem einen funktionierenden Checkout. Das ist, was gutes Schneiden dir kauft.

Den Muskel als Team aufbauen? Macht eine Elephant-Carpaccio-Session: Nehmt ein Feature und zwingt es in die dünnsten vertikalen Scheiben, die ihr hinbekommt, jede einzeln vorzeigbar. Alistair Cockburn, der die Übung erfunden hat, weist darauf hin, dass der Name verkehrt herum ist. Du schneidest keine Scheiben von einem fertigen Elefanten ab. Du baust den Elefanten Scheibe für Scheibe auf.¹⁹

Ein schlechtes Ticket beim Lesen zu riechen ist gut. Es zu fangen, bevor es überhaupt jemand liest, ist besser. Dafür ist das Refinement da, und es muss nicht schwer sein.

Eine Definition of Ready ist eine kurze gemeinsame Übereinkunft, dass ein Ticket genug verstanden ist, um zu starten: Es hat einen genannten Wert, hat testbare Akzeptanzkriterien, ist klein genug und seine Abhängigkeiten sind bekannt.²⁰ Behandle sie aber als Leitplanke, nicht als Tor. Eine starre Definition of Ready wird leise zu einem Mini-Wasserfall, einem Stage Gate, an dem "Refinement" an "Entwicklung" übergibt, also genau jene Übergabe großer Batches, vor der Lean Flow warnt.²¹ Die Messlatte heißt "wir wissen genug, um zu starten, und passen unterwegs an", nicht "jede Frage vorab beantwortet".

Mach Refinement zur Gewohnheit, nicht zum Termin. Mike Cohns Faustregel ist, etwa fünf bis zehn Prozent jedes Sprints darauf zu verwenden und nur "ausreichend verstanden" anzustreben, nicht perfekt spezifiziert.²² Macht in dieser Zeit einen Three-Amigos-Durchgang über alles Unklare, mappt per Example Mapping alles, was ihr nicht in einem Satz erklären könnt, und teilt alles, was größer als ein paar Tage ist, an Ort und Stelle.

Bevor ein Ticket aufs Board kommt, lass es diese Fragen durchlaufen. Ein "Nein" ist kein Veto. Es ist ein Anstoß, zu reden, zu teilen oder es zurückzuschicken.

• Der Wert ist explizit. Du kannst sagen, wer profitiert und warum, das "damit".
• Akzeptanzkriterien sind geschrieben und testbar. Eine Testerin könnte sie heute in Prüfungen verwandeln.
• Keine offene Frage blockiert den Start.
• Es ist klein genug, um in ein paar Tagen bequem fertig zu werden.
• Es ist unabhängig, oder jede Abhängigkeit ist benannt und verfolgt.
• Das Team ist sich über die Größe einig, keine breite Streuung bleibt unerklärt.
• Drei Perspektiven haben es gesehen: Produkt, Entwicklung und Test.
• Du könntest es in etwa 25 Minuten mappen. Wenn nicht, ist es zu groß oder zu vage.

Du brauchst keine Prozessrevolution. Such dir ein paar davon aus und mach sie.

• Häng den Smell-Test an die Wand und prüfe Tickets im Refinement dagegen.
• Mach "zurückschicken" zu einem normalen, schuldfreien Zug. Ein fehlendes "damit" oder kein testbares Kriterium geht zurück an den Autor, nicht in den Sprint.
• Wenn Schätzungen breit streuen, halt inne und rede, bevor du mittelst. Die Lücke ist das wertvollste Signal im Raum.
• Teile alles, was länger als ein paar Tage dauert, vertikal, an Ort und Stelle. Halte SPIDR und die Humanizing-Work-Muster als Spickzettel bereit.
• Beobachte das Work Item Age, nicht nur den Burndown. Wenn ein Ticket über euer Übliches hinaus altert, greif ein, bevor es zu spät ist.

Der Gewinn sind nicht ordentlichere Tickets um ihrer selbst willen. Es ist ein Sprint, der so endet, wie er am Montag aussah. Die bösen Überraschungen hören auf, sich im Gebüsch zu verstecken, sobald das ganze Team sie kommen riechen kann.

• INVEST in Good Stories, and SMART Tasks (Bill Wake)

  Der Ursprung der INVEST-Checkliste von 2003 und der Kuchen-Metapher. Die beste Ein-Seiten-Referenz dazu, was eine gute Story ausmacht.

• SPIDR: Five Simple but Powerful Ways to Split User Stories (Mike Cohn)

  Fünf konkrete Achsen, um fast jede Story zu teilen und dabei jedes Stück als vertikalen, lieferbaren Schnitt zu erhalten.

• The Humanizing Work Guide to Splitting User Stories

  Der meistgeladene Leitfaden zum Story-Splitting: ein Flussdiagramm, neun Muster und zwei Faustregeln für die Wahl zwischen Schnitten.

• User Story Splitting: Vertical vs Horizontal Slice (Visual Paradigm)

  Warum das Teilen nach technischer Schicht Übergaben und Verzögerung erzeugt, und wie ein vertikaler Schnitt stattdessen aussieht.

• Introducing Example Mapping (Matt Wynne, Cucumber)

  Die 25-minütige Vier-Karten-Refinement-Technik, die Regeln, Beispiele und die verborgenen offenen Fragen eines Tickets sichtbar macht.

• The Curse of Knowledge (Harvard Business Review)

  Chip und Dan Heath darüber, warum Experten undurchsichtige Anweisungen schreiben, mit der Klopfer-und-Zuhörer-Studie hinter dem Klopfer-Smell.

• 4 Key Flow Metrics and How to Use Them (Scrum.org)

  Cycle Time, Durchsatz, WIP und Work Item Age: die Linse, die einen stehenden Felsbrocken sichtbar macht, bevor er zu spät ist.

• What is a Definition of Ready? (Atlassian)

  Eine praktische DoR-Checkliste, an INVEST gekoppelt, nützlich als Leitplanke, solange du sie nicht zu einem Stage Gate erstarren lässt.