Was ist eine gute User Story?

von tinatigertech

Wichtiger Bestandteil agiler Projektplanung ist das Schreiben von User Stories. Hierbei gilt es zu verstehen was eine User Story genau ausmacht und wie sie sich von den aus anderen Entwicklungsmethoden bereits bekannten Use Cases unterscheidet. User Stories dienen grundsätzlich demselben Zweck wie Use Cases, beide beschreiben Anforderungen an das System, sie sind aber nicht das Gleiche. User Stories werden zusätzlich dazu benutzt, um Zeitschätzungen in die Release-Planung einzubringen. Außerdem dienen sie als Ersatz für umfangreiche Anforderungsdokumente.

Alistair Cockburn, der international bekannte IT Stratege, Buchautor und Mitbegründer des Agile Development Manifesto hat sich intensiv mit der Definition von Use Cases und User Stories auseinandergesetzt.

Er versucht den Unterschied wie folgt zu erklären: Eine User Story ist wie die Überschrift eines Szenarios, möglicherweise zusammen mit einem Beispiel. Ein Use Case beschreibt den Inhalt mehrerer Szenarien zur Nutzung einer Software. Er weist darauf hin, daß neben User Stories durchaus auch weiterhin Use Cases verwendet werden dürfen, wenn es für das Team hilfreich ist. Wie schwierig diese Unterscheidung dann aber doch ist, zeigt seine sehr lustige Diskussion zu dem Thema „A user story is to a use case as a gazelle is to a gazebo“, die seit 2007 bis heute fortgeführt wird.

User Stories werden aus Sicht des Nutzers geschrieben

User Stories benennen Dinge, die das zu implementierende System für den Anwender tun soll. Sie sind dessen vorrangige Art die Funktionalität des zu entwickelnden Systems zu beeinflussen. User Stories sind für jeden verständlich und drücken den Kundennutzen klar aus. Dies erleichtert vor der Umsetzung die Konversation über die Stories und läßt während der Umsetzung noch genug Spielraum für technische Alternativen. Eine User Story erfasst das „wer“, „was“ und „warum“ einer Anforderung auf einfache, präzise Art und Weise, oft mit eingeschränktem Detailgrad, sodaß sie auf eine handgeschriebene Karteikarte passt. Der Product Owner ist dafür verantwortlich die User Stories zu formulieren. Der Entwickler kann Vorschläge machen, ob bestimmte Funktionalitäten gewünscht sind, aber muss aufpassen, daß er den kreativen Ideenfindungsprozess nicht dominiert. User Stories sind nicht endgültig festgelegt, wenn sie geschrieben worden sind, da Anforderungen dazu tendieren sich während dem Entwicklungsprozess zu ändern.

Aufbau einer User Story

User Stories haben normalerweise den folgenden Aufbau:

Als (Anwendertyp) möchte ich (folgende Aktion durchführen), um (daraus einen bestimmten Nutzen zu ziehen).

Wer: Wichtig ist möglichst klar darzustellen, von wem die Anforderung überhaupt kommt. Vermutlich am häufigsten anzutreffen sind User Stories mit dem Anwendertyp “Benutzer”. Es kann jedoch deutlich spezifischer zum Ausdruck gebraucht werden, um welchen Benutzer es sich handelt. Z.B. durch eine Ergänzung wie “als Benutzer mit einem Twitter-Account”. Das ist schon ein ganzes Stück spezifischer und hilft allen Beteiligten einzuschätzen, wie groß die Nutzergruppe ist und woher ihr Wunsch kommt.

Was: In diesem Teil wird dargelegt, welche Funktionalität zur Realisierung des Nutzens implementiert werden soll. User Stories können einen sehr unterschiedlichen Grad an Genauigkeit annehmen, je nachdem wie weit die Umsetzung fortgeschritten ist.

Warum: Hier geht es um den zu Grunde liegenden Nutzen, der erreicht werden soll. Die beschriebene Funktionalität soll aus dem Nutzen für den Anwender abgeleitet sein. Ein Benutzer will sich z.B. nicht als Selbstzweck bei einer Softwareanwendung anmelden, sondern macht dies nur, um die Kernfunktionen der Software anschließend nutzen zu können.

Beispiele:

  • Als Autor muss ich das Löschen meines Dokuments bestätigen, um ein versehentliches Löschen zu verhindern.
  • Als nicht-administrativer Nutzer möchte ich die Daten meiner Kunden per Excel-File herunterladen können, um damit außerhalb der Anwendung Serienbriefe zu erstellen.
  • Als ein Tester der mobilen Applikation, möchte ich meine Testcases auswerten, um Berichte für das Management zu erstellen.
  • Als ein Nutzer der die Anwendung schließt, möchte ich gefragt werden, ob ich alles speichern möchte was ich geändert habe, um nützliche Arbeiten zu speichern oder fehlerhafte zu verwerfen.

User Stories steuern die Erstellung von Akzeptanz Tests

Jeder User Story werden Akzeptanz Kriterien zugeordnet, um festzustellen, wann die User Story entsprechend ihren Anforderungen umgesetzt wurde. Auf dieser Grundlage können die Entwickler Akzeptanz Tests schreiben und der Kunde oder der Produkt Owner kann die Software anhand dieser Kriterien abnehmen. Die Akzeptanz Kriterien beantworten die Frage, was getestet werden soll. Sie formulieren Bedingungen, die erfüllt sein müssen:

  • Der Nutzer kann die Daten aller Kunden als Excel-File herunterladen.
  • Ich kann die Daten für alle zur Auswahl stehenden Zeiträume ausgeben lassen.
  • Ich werde gefragt, ob ich beim Schließen der Anwendung meine Daten speichern möchte.

Eine Möglichkeit zur Formulierung von Akzeptanz Kriterien kann auch sein, dass sie mit “Teste…” anfangen, damit man sie direkt für Akzeptanz Tests verwenden kann. Beispiele dafür könnten sein:

  • Teste die Eingabe eines ungültigen Benutzernamens.
  • Teste die Eingabe eines ungültigen Passworts.

Grundregeln zur Erstellung einer User Story – die 3 C´s

Gut merken kann man sich drei Grundregeln für die Erstellung von User Stories, die Ron Jeffries, erfahrener XP Autor, Coach und Nutzer, bereits 2001 in seinem Blog XProgramming.com vorstellt.

Card: Eine User Story sollte so kurz und prägnant sein, daß sie auf einer Karteikarte Platz hat.

Conversation: Es sollte mehrfacher persönlicher Austausch über eine UserStory zwischen Kunde/Product Owner und Entwicklerteam stattfinden. Die Kommentare werden meist auf der Rückseite der Karte erfasst.

Confirmation: Durch die Festlegung von Akzeptanzkriterien kann die erfolgreiche Umsetzung einer User Story vom Kunden abgenommen werden.

Kriterien für eine gute User Story – INVEST

Die Eselsbrücke INVEST wurde 2003 von Bill Wake, Senior Consultant bei Industrial Logic und Experte in der Schulung von Teams in agiler Software-Entwicklung, als eine Gedächtnisstütze für die Eigenschaften einer guten User Story entwickelt.

  • Independent: Eine Story sollte unabhängig von anderen Stories sein. Story-Ketten sollten demnach vermieden werden.
  • Negotiable: User Stories sind verhandelbar und können verändert werden. Kunden und Entwickler besprechen und präzisieren sie gemeinsam.
  • Valuable: Die Stories sollten einen erkennbaren Mehrwert für den Endnutzer liefern. Deshalb sollten sie vom Nutzer selbst geschrieben werden.
  • Estimatable: Eine Story muss so überschaubar sein, dass die Entwickler die Zeit und den Aufwand für die Umsetzung abschätzen können.
  • Small: Die komplette Umsetzung einer Story sollte in einem Sprint erfolgen können. Ein Sprint kann 1 oder auch 2 Wochen dauern.
  • Testable: Klare Akzeptanz Kriterien legen feste, wann eine Story erfolgreich abgeschlossen und testbar ist.

Zusammenfassung

Das Arbeiten mit User Stories erfordert eine gewissen Einarbeitungszeit und Gewöhnung bis alle Beteiligten eine gemeinsame Vorstellung davon entwickelt haben, wie umfangreich, detailiert und sauber die User Stories ausgearbeitet werden müssen. Wichtig sind hierfür regelmäßige Backlog Grooming-Sitzungen mit allen Projektbeteiligten, in denen die Stories durchgegangen, im Aufwand geschätzt und priorisiert werden. Hierfür kann als Tool das Rapid Board von Greenhopper in JIRA verwendet werden (Siehe Artikel Agile Projektplanung für Scrum- und Kanbanteams mit dem Rapid-Board).

Gute User Stories zu schreiben ist nicht so einfach. Gut umgesetzt helfen sie aber dabei, bessere Software zu schreiben und sie näher am Nutzer zu orientieren.

Links:

Literatur:

Schreibe einen Kommentar