Ein Kunde kontaktiert den Support per WhatsApp. Während er darauf wartet, mit einem Menschen verbunden zu werden, erhält er eine Reihe von Nachrichten mit Updates zu seiner Wartezeit. Die Nachrichten lauten: "Sie warten seit 1 Minute." Dann "Sie warten seit 2 Minuten." Dann "Sie warten seit 3 Minuten."

Der Text sagt "Wartezeit", was impliziert, wie lange noch gewartet werden muss. Der Entwickler hat es als die bereits verstrichene Zeit umgesetzt. Das Ergebnis: Der Kunde erwartet, gleich bedient zu werden, und erhält stattdessen einen laufenden Zähler seiner Frustration. Nicht ideal.

Das ist keine Geschichte über einen unachtsamen Entwickler. Es ist eine Geschichte darüber, was passiert, wenn Anforderungen spezifiziert werden, ohne ein echtes gemeinsames Verständnis davon, was der Nutzer tatsächlich braucht.

Woher User Stories kommen

User Stories haben einen interessanten Ursprung. Kent Beck, der Begründer von Extreme Programming, wurde von einem Nutzer angesprochen, der von einer neuen Funktion so begeistert war, dass die Idee entstand: Was, wenn statt zu spezifizieren, was gebaut werden soll, zunächst artikuliert würde, welche Reaktion beim Nutzer erhofft wird, wenn er sie erhält?

Ron Jeffries entwickelte dann die Vorlage, die die meisten Teams heute kennen: Als [Art von Nutzer:in] möchte ich [eine Funktion], damit [ein Wert entsteht]. Die Vorlage ist nicht der Punkt. Die drei C's, die Jeffries ebenfalls einführte, sind der Punkt: Card, Conversation und Confirmation.

Die Card ist eine kurze Beschreibung, ein Platzhalter für ein Gespräch, keine vollständige Spezifikation. Die Conversation ist die Diskussion zwischen Entwickler:innen, der Product-Owner-Person und idealerweise echten Nutzenden darüber, was die Story bedeutet, was der Nutzer tatsächlich erreichen möchte, und welche Randfälle wichtig sind. Die Confirmation sind die Akzeptanzkriterien, die geteilte Vereinbarung darüber, wie "fertig" aussieht.

Wie die meisten Teams sie falsch nutzen

Der Fehler ist, User Stories als Anforderungsformat statt als Gesprächskatalysator zu behandeln. Das erzeugt Stories wie:

Als Entwickler möchte ich eine Datenbank, damit ich Daten speichern kann.

Oder ganze Jira-Tickets mit hunderten Wörtern angehängter Spezifikation, was einfach ein Anforderungsdokument in anderer Verpackung ist.

Das sind keine User Stories. Sie haben keinen Nutzer. Sie spezifizieren, was gebaut werden soll, ohne zu erklären, warum es wichtig ist oder wie die Nutzererfahrung aussehen sollte. Sie schließen das Gespräch, statt es zu öffnen.

Das Wartezeit-Beispiel veranschaulicht perfekt, was das erzeugt. Jemand hat spezifiziert, dass es eine "Wartezeit"-Nachricht geben soll. Niemand hat das Gespräch darüber geführt, was "Wartezeit" für den wartenden Nutzer bedeutet, nämlich wie lange er noch warten muss, nicht wie lange er schon gewartet hat. Der Entwickler hat genau das gebaut, was spezifiziert wurde. Die Spezifikation war falsch.

Bessere User Stories schreiben

Das Format, Als, möchte ich, damit, ist ein Gerüst, keine Garantie. Was eine User Story nützlich macht, ist die Klarheit ihrer drei Komponenten.

Der Nutzer sollte eine reale Person oder Persona sein, deren Bedürfnisse das Team versteht. "Als Nutzer" ist fast nie spezifisch genug. "Als Kunde, der auf Support wartet und entscheiden muss, ob er in der Warteschleife bleibt oder später zurückruft" ist spezifisch genug, um ein nützliches Gespräch zu erzeugen.

Die Funktion sollte Absicht beschreiben, nicht Umsetzung. "Ich möchte wissen, ob sich mein Warten lohnt" ist nützlicher als "Ich möchte eine Nachricht mit der Wartezeit", weil es die Frage öffnet, welche Information das eigentliche Bedürfnis des Nutzers tatsächlich beantworten würde.

Der Wert erklärt das Warum. Das ist der Teil, der am häufigsten weggelassen wird, und oft der wichtigste: Es ist der Test, an dem die Umsetzung letztlich gemessen wird.

Das Gespräch rund um eine gut konstruierte User Story ist, wo die eigentliche Spezifikationsarbeit geschieht. Die Card ist nur eine Möglichkeit, es zu beginnen.