User Stories. Mehr als nur ein Template.

User Stories haben sich zu einem Standard für Einträge im Product Backlog entwickelt. Als leichtgewichtige und nutzerzentrierte Anforderungen passen sie sehr gut in den Kontext von Scrum. In der Praxis werden sie fälschlicherweise oft auf eine vermeintliche Funktion als Template oder auf ihre bloße Formulierung reduziert und verfehlen damit häufig ihren eigentlichen Zweck: in enger Zusammenarbeit den Kundennutzen aufzuzeigen. In Podcast-Folge #17  „User Stories“ gehe ich auf diese Problematik ein und verdeutliche, warum User Stories mehr sind als nur ein Format und dass es wichtig ist, ihre Intention zu verstehen. Darüber hinaus gehe ich darauf ein, was gute User Stories auszeichnet und wie wir diese effektiv nutzen können.  

User Stories passen perfekt in den Kontext von Scrum.

Warum User Stories so gut zu Scrum passen liegt hauptsächlich daran, dass wir in Scrum ein Entwicklungsteam haben, das alle Fähigkeiten zur Lösung einer Problemstellung besitzt. Weil in Scrum ein wesentlicher Teil der Lösungsentwicklung im Sprint selbst stattfindet, sind wir in der Lage, mit leichtgewichtigen Informationen und ohne ausufernde Spezifikation in den Sprint zu starten. Ebenso ist es in unserer crossfunktionalen Zusammenarbeit möglich, Synergien zu nutzen und eng mit unseren Kunden zusammenzuarbeiten. Wir können lange Vorlaufzeiten in der Vorbereitung reduzieren und  schnell wertstiftende Ergebnisse schaffen. Indem sie kurz und knapp die Anforderungen aus Nutzersicht beschreiben, liefern uns User Stories liefern genau den leichtgewichtigen Input, mit dem wir in den Sprint starten können.  Sie passen perfekt in diesen Kontext und ermöglichen es uns, mit Scrum agil zu arbeiten.

User Stories sind mehr als ein Template

Eine User Story soll auf eine leichtgewichtige und nutzerzentrierte Art Aufschluss über die Anforderungen an das Produkt geben. Sie soll die relevanten Informationen transportieren, um in den Sprint zu starten. Ein festgeschriebenes Format gab es dafür nicht. In der Vergangenheit kam es allerdings häufig vor, dass relevante Informationen an der ein oder anderen Stelle gefehlt haben. Aus diesem Missstand heraus kam die Idee auf, ein Template zu erstellen. Dieses Template sollte sicherstellen, dass alle notwendige Informationen in der User Story enthalten waren. 

Eine typische User Story verfolgt folgende Struktur: 

• Als … (Nutzer XY)
• möchte ich …   (Ziel)   
• sodass ich …  (Benefit)

Neben der Sicherstellung der Vollständigkeit ist ein weiterer positiver Effekt, dass durch die einheitliche Formulierung konsistenter und einfacher mit User Stories gearbeitet werden kann. Ein negativer Nebeneffekt dieser Vereinheitlichung ist, dass die User Stories häufig auf ihre Funktion als Template reduziert werden. Man konzentriert sich häufig mehr auf das Formulieren und Ausfüllen eines Templates, als sich vor Augen zu halten, dass diese leichtgewichtigen Anforderungen aus Nutzersicht erst in einer engen Kollaboration zwischen Team und Product Owner im Sprint ihr wahre Wirkung entfalten. Tatsächlich soll dieses Template ein Hilfsmittel darstellen, das als Ergänzung dazu genutzt wird.

User Stories lösen das “Stille Post”-Problem

Um zu verdeutlichen, welches Problem User Stories eigentlich lösen, rede ich gern von einem “Stille Post” Problem”. Früher (vor einer agilen Arbeitsweise) wurde der Kunde für gewöhnlich insofern eingebunden, als dass er in einem ersten Gespräch seine Anforderungen und Wünsche geäußert hat. Im weiteren Verlauf spielte der Kunde erst dann wieder eine Rolle, wenn das Produkt geliefert wurde. Der Kunde stand am Anfang und am Ende der Kette. Diese Kette erinnert stark an das Kinderspiel “Stille Post”, bei dem Kinder in einer Reihe stehen, sich Kinder nacheinander ein Wort ins Ohr flüstern und am Ende der Kette feststellen, dass es nicht im Ansatz dem ursprünglichen Wort entspricht. Was als Kind noch spaßig war bedeutet allerdings in unserem Fall, dass, selbst wenn die Kette funktioniert und am Ende das richtige Ergebnis hervorgebracht wird, der Kunde in der Zwischenzeit bei der Entwicklung außen vor ist. Ohne Einbindung des Kunden können wir weder mit ihm gemeinsam lernen, noch auf geänderte Anforderungen reagieren. Im allerschlimmsten Fall jedoch funktioniert die Kette nicht und der Kunde erhält am Ende ein Produkt, das seine Anforderungen anders widerspiegelt, als erwartet. In einem komplexen Umfeld kann diese Vorgehensweise nicht zu zufriedenstellenden Ergebnissen führen, denn es ist sehr wahrscheinlich, dass sich die Gegebenheiten zwischenzeitlich ändern. 

Um das dieses “Stille Post” Szenario zu vermeiden, arbeiten wir in einem komplexen Umfeld mit Scrum und demnach auch mit User Stories. Die Intention dahinter ist ganz einfach: um die Lösungen möglichst nah am Kunden zu entwickeln, erstellen wir eine priorisierte Liste an Items, die den Kunden glücklich machen. Diese “Kunden-Glücklichmach-Items”  sind einfach verständlich und können daher problemlos auch direkt mit dem Kunden besprochen werden. Sie werden erst im Sprint in ihre einzelnen Tasks heruntergebrochen und technisch konkretisiert. Falls ein Thema für den Sprint zu groß ist, wird es aus Nutzersicht vereinfacht (nicht aus technischer Sicht). 

Konkret bedeutet das, wenn wir beispielsweise auf einer Webseite vier Bezahlmöglichkeiten implementieren wollen und diese für einen Sprint zu groß sind, erarbeiten wir in crossfunktionaler Zusammenarbeit im Sprint zuerst eine. Diese eine Möglichkeit stellt einen Anwendungsfall dar, der für den Nutzer verständlich ist und der im Review abgestimmt werden kann. Im Kern versuchen wir, unsere technische Expertise nutzerzentriert einzusetzen um im Dialog mit dem Kunden das bestmögliche Ergebnis zu erzielen.

Drei C’s: Kennzeichen einer guten User Story

Um aus einer User Story eine gute User Story zu machen, betrachten wir 3 C’s. Sie fassen kurz und eindrücklich zusammen, worauf zu achten ist, um eine User Story gut zu formulieren und effektiv zu nutzen. 

• Conversation
  User Stories stellen ein agiles Tool dar und verfolgen wie alle agile Werkzeuge den Zweck, ein Gespräch anzuregen oder zusammenzufassen. Im Zentrum von User Stories steht daher nicht die geschriebene Anforderungen aus Nutzersicht, sondern der leichtgewichtige Dialog, der ihnen zugrunde liegt. Ein Dialog umfasst hierbei sowohl das Gespräch zwischen Kunde und Product Owner sowie zwischen Product Owner und Entwicklungsteam.
• Card
  Damit unsere User Story gut ist, konzentrieren wir uns auf das Wesentliche. Und das bedeutet, dass sie in einem kleinen Format, beispielsweise auf einer Indexkarte, dargestellt werden kann. Dies hat den Vorteil, dass das Team alles Wesentliche während des Sprints im Blick hat und schnell darauf zurückgreifen kann.
• Confirmation
  User Stories sollten zudem grob den Umfang abstecken. Würde man diesen nicht vermerken, könnte diese eine Anforderung dennoch unterschiedlich ausgelegt werden und beispielsweise aus einem Foodtruck ein Sterne-Restaurant machen. Auch hier sollte man sich wieder auf das Wesentliche konzentrieren. Etwa drei bis sieben Akzeptanzkriterien auf der Rückseite der Indexkarte sind angemessen.

Was ist der Unterschied zu einem Epic?

Der Unterschied zwischen User Story und Epic liegt in der Größe der Items. Der Name „Eric“ entstand aus der anfänglichen Frage, wie sich große Items im Backlog eigentlich nennen. Ein Epic stellt im Grunde ebenfalls eine User Story dar. Sie ist lediglich zu groß, um direkt in den Sprint mit aufgenommen zu werden und wird daher in mehrere kleine User Stories herunter gebrochen. Um eine Unterscheidung zu schaffen und dieser “epischen Geschichte” den passenden Namen zu verleihen, etablierte sich der Begriff Epic. 

Die Grundlage für die leichtgewichtige Arbeitsweise mit User Stories

Wie bereits beschrieben, passen User Stories aufgrund ihrer Leichtgewichtigkeit genau zur agilen Arbeitsweise mit Scrum. Die Grundlage für den Einsatz von User Stories ist demnach ein Umfeld, das für diese Arbeitsweise gut aufgestellt ist. Es genügt nicht, in einer klassischen Arbeitsweise mit User Stories zu arbeiten. Vielmehr ist es wichtig, ein  crossfunktionales Team zu haben, das alle Fähigkeiten besitzt, um eigenverantwortlich mit diesen leichtgewichtigen Items zu arbeiten und damit die Verantwortung für die Lieferung von konsistenten Lösungen zu übernehmen. Ergänzend dazu benötigt es ein Vertrauensverhältnis zwischen Product Owner und Team, welches sich in der Zusammenarbeit aufbaut und Sprint für Sprint festigt. Darüber hinaus ist es wichtig, eine Umgebung zu schaffen, in der sich Stakeholder auf eine gröberen Ebene mit den Anforderungen von Items auseinandersetzen und erst in der Ausgestaltung im Sprint eine Granularität entwickelt, aus der das Team lernt. 

Zusammenfassung

User Stories sind leichtgewichtige Nutzergeschichten, die oft fälschlicherweis reduziert werden auf ihre vermeintliche Funktion als Template. Die Nutzung eines Templates zur Beschreibung der User Story ist zwar hilfreich, jedoch nicht die primäre Intention, die sich dahinter verbirgt. User Stories regen Gespräche an, oder stellen die Zusammenfassung eines Gesprächs dar. Darüber hinaus zeichnet ein gute User Story sich dadurch aus, dass sie sich hinsichtlich Inhalt und Umfang auf das wesentliche konzentriert.

Ich hoffe, ich konnte dir die zugrundeliegende Intention von User Stories näher bringen und neue Impulse für die Erstellung von User Stories geben. Hast du Fragen oder Anmerkungen? Ich freue mich über Feedback.