Eine User Story („Anwendererzählung“) ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze.
User Stories werden im Rahmen der agilen Softwareentwicklung (z. B. Extreme Programming (XP), Scrum) zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. Dabei wird jede User Story auf eine Story-Card geschrieben. Der Autor der Story sollte der Kunde des Software-Projektes sein.
User Stories erstellen Bearbeiten
User Stories können entweder formlos angelegt werden oder unter Verwendung einer Vorlage:[1]
"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"
Beispiele Bearbeiten
Das folgende Beispiel verwendet die Vorlage "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>":
Anwendung starten:
- Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.
Die beiden folgenden Beispiele zeigen den Aufbau aus jeweils einer Überschrift und einem einzigen Satz in freier Form. Im ersten Beispiel ist nicht klar, wer der Autor ist. Im zweiten ist nicht klar, was "beenden" genau ist.
Anwendung starten:
- Die Anwendung startet, indem sie das zuletzt bearbeitete Dokument des Anwenders öffnet, damit der Anwender Zeit spart.
Anwendung schließen:
- Wenn der Anwender die Anwendung beendet, erscheint eine Anfrage, ob das bearbeitete Dokument gespeichert werden soll, damit Änderungen nicht verloren gehen.
Story Decomposition Bearbeiten
Story Decomposition stellt sicher, dass die User Stories in einem adäquaten Detaillierungsgrad beschrieben werden, und dass die User Stories sich aus den Anwenderzielen ableiten. Dabei wird von der Breite in die Tiefe vorgegangen, um die Anforderungen nach und nach zu verfeinern: Ausgangspunkt bilden die zu erreichenden Anwenderziele; daraus werden Epics abgeleitet, die in User Stories zerlegt werden; die User Stories werden um Akzeptanzkriterien ergänzt.
Story-Card Bearbeiten
Als Story-Card wird das Medium beschrieben, auf dem eine User Story dokumentiert wird, üblicherweise Zettel (z. B. Klebezettel) oder Computerdatensätze.
Die Story-Cards dienen insbesondere als Kommunikationsmittel zwischen Anforderern und Umsetzern. Die Story-Card enthält die Beschreibung der Story, üblicherweise in Form eines Satzes nach der oben beschriebenen Vorlage. Weiterhin kann das Ergebnis einer Schätzung, zumeist in Form von Story-Points, direkt auf der Story-Card festgehalten werden.
Traditionell enthält die Rückseite der Story-Card die Beschreibung der Akzeptanzkriterien der User Story. Wenn die Rückseite allerdings nicht zugänglich ist und/oder mehrere Akzeptanzkriterien für eine User Story definiert werden müssen, können diese auch auf getrennten Zetteln oder in einem Computersystem erfasst sein.
Mit den Akzeptanzkriterien beschreibt der Anforderer, wie er die korrekte Umsetzung der User Story testen würde. Dies ist sowohl für das Verständnis, als auch für den Test der User Story hilfreich. Bei Änderungen sollte zudem das zu ändernde Verhalten dokumentiert sein.
Bei der Verwendung von Behavior Driven Development werden diese Akzeptanzkriterien in Form von Sätzen mit definierter Struktur verfasst. Hierbei wird insbesondere die Gherkin-Syntax verwendet, um eine automatische Testbarkeit zu ermöglichen. Die Beschreibung der Story auf der Story-Card dient hierbei als konzeptionelle Verbindung der Story-Card mit den zugehörigen Akzeptanzkriterien. Da die Akzeptanzkriterien klar, präzise und (zumindest prinzipiell) automatisch testbar sein müssen, können sie sehr umfangreich ausfallen.
User Story Map Bearbeiten
Eine User Story Map zeigt User Stories in einer grafischen Übersicht. Horizontal werden die aufeinanderfolgenden Aktivitäten des Anwenders jeweils mit einer User Story dargestellt. Vertikal wird von oben nach unten detailliert: z. B. angefangen bei den Kundenzielen über Epics bis hin zu den User Stories. Durch eine User Story Map wird ein Überblick über alle User Stories hergestellt.
Abgrenzung User Story zu Use Case Bearbeiten
Die Use Cases in der klassischen Softwareentwicklung ohne agile Methoden sind User Stories insofern ähnlich, als sie Anforderungen in der Sprache des Anwenders und im Kontext darstellen.
Bei einem Use Case werden jedoch alle Erfolgs- und Misserfolgsszenarien bei der möglichen Erreichung eines fachlich relevanten Ziels gebündelt dargestellt.[2] Eine User Story stellt hingegen eine fachlich motivierte Anforderung dar, die von einem Anwender zwar als erfolgreich bzw. nicht erfolgreich umgesetzt beurteilt werden kann, allerdings wird der Anwender allein mit der User Story kein fachliches Ziel erreichen können.
Somit kann ein Use Case den Kontext für viele User Stories bilden: Eine User Story ist die Überschrift eines konkreten Szenarios, ein Use Case beinhaltet mehrere dieser Szenarien.[3]
Literatur Bearbeiten
- Mike Cohn: User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a. mitp, Bonn 2010, ISBN 978-3-8266-5898-3.
- Daniel H. Steinberg, Daniel W. Palmer: Extreme Software Engineering. A Hands-on Approach. Pearson Prentice Hall, Upper Saddle River, New Jersey 2004, ISBN 978-0-13-047381-3.
- Ralf Wirdemann: Scrum mit User Stories. 2. Auflage. Hanser, München 2011, ISBN 978-3-446-42660-3.
Weblinks Bearbeiten
Einzelnachweise Bearbeiten
- ↑ Scott W. Ambler: Introduction to User Stories. Initial User Stories (Formal). In: Agile Modeling. Abgerufen am 20. März 2014 (englisch).
- ↑ Alistair Cockburn: Use Cases effektiv erstellen. mitp, Bonn 2003, ISBN 3-8266-1344-9, S. 231.
- ↑ Jens Coldeweys: Methodik: Use Cases, User Stories und Akzeptanztests. Abgerufen am 20. März 2014 (deutsch).