Hauptgedanke

Die User Story war als Versprechen auf ein Gespräch gedacht: ein kurzer, absichtlich unvollständiger Satz, dessen Aufgabe es ist, die richtigen Leute um das Thema zu versammeln. Als Vertrag behandelt, wird sie zum Gegenteil – zu einem Text, den man umsetzt, ohne mit seinem Verfasser zu sprechen, und mit dem man hinterher feststellt, wer im Unrecht war.

Die praktische Folge betrifft den, der die Karte bekommt. Ein Entwickler sollte kein Ticket akzeptieren, das er nicht versteht: Fehlen Elemente, um die Machbarkeit zu beurteilen, fordert er sie ein; fehlt der fachliche Kontext, fordert er ihn ein; sieht er den Wert nicht, sagt er es. Diese Weigerung ist kein Einwand aus Prinzip, sie ist die Gebrauchsanweisung des Artefakts.

Warum das wichtig ist

Das verschiebt die Verantwortung für die Qualität eines Tickets. Sie liegt nicht vollständig bei dem, der schreibt: Die Karte ist ein Ausgangspunkt, und wer sie übernimmt, ist verpflichtet, sie vervollständigen zu lassen.

Es erklärt auch, warum die ständige Verbesserung der Vorlagen nichts löst. Was einem unverstandenen Ticket fehlt, ist kein zusätzliches Feld, sondern ein Gespräch, das nicht stattgefunden hat.

Nuancen und Grenzen

Nicht jede Organisation kann sich auf das Gespräch verlassen: ein entferntes Team über mehrere Zeitzonen, ein externer Dienstleister, eine vertragliche Beziehung. Das Geschriebene trägt dort eine Last, für die es nicht gemacht war, und das muss man als Kosten hinnehmen, nicht als Norm.

Und ein Entwickler, der jede Karte hinterfragt, kann auch den Fluss blockieren: Wer um Klärung bittet, muss echtes Fehlen von bloßem Unbehagen unterscheiden können.

Offene Fragen

• Wer bezahlt für das Gespräch, das nicht stattgefunden hat, wenn die Lieferung dem entspricht, was geschrieben stand?