Ratgeber

Scrum: Was User-Storys sind und wie ihr sie schreibt

(Foto: Shutterstock)

User-Storys sind ein Hilfsmittel in agilen Methoden der Software-Entwicklung und schlagen die Brücke zum Kunden. Sie halten Anforderungen in Alltagssprache aus der Sicht des Anwenders fest.

User-Storys haben ihren eigentlichen Ursprung im Extreme Programming. Heute finden sie aber auch in weiteren agilen Software-Methoden ihre Anwendung. In Scrum beispielsweise sind sie nicht mehr wegzudenken und ein wichtiger Bestandteil.

Passend dazu: Extreme Programming im Silicon Valley – so arbeitet Pivotal

Was ist eine User-Story?

Eine User-Story ist im Grunde genau das, was der Name schon sagt: eine kurze Geschichte aus der Sicht des Nutzers. Dabei wird immer eine bestimmte Anforderung gestellt – an die Software sowie in einfacher Alltagssprache, und damit für jeden verständlich. So sind User-Storys eine gute Möglichkeit, die Ideen und Wünsche verschiedener Parteien, also Kunde, Programmierer, Designer, Product-Owner und so weiter, zusammenzutragen. Sie dienen also als wichtiges Kommunikationsmittel. Verfasst wird jede User-Story auf eine eigene, sogenannte Story-Card. Die Karten können klassische Klebezettel, Karteikarten oder auch digital sein. Später können Story-Cards auf verschiedene Art und Weise geordnet werden – als User-Story-Map beispielsweise. Die wohl verbreitetste digitale Lösung dafür ist Jira von Atlassian. Es gibt aber auch einige weitere Alternativen von Open Source bis kostenpflichtig.

Wer erstellt User-Storys und wie werden sie verwaltet?

Der Kunde sollte beim Erstellen und Priorisieren der User-Storys auf jeden Fall mit einbezogen werden. Autor einer Story ist entweder direkt der Kunde, der Product-Owner oder andere Projektteilnehmer, die den Bedarf für den Anwender identifizieren können. Für das Verwalten, Ordnen und Priorisieren ist, unter Umständen mit Einbezug des Kunden, der Product-Owner verantwortlich. Dadurch können Programmierer und Designer während der Entwicklung auf die User-Storys zurückgreifen und wissen somit, was zu implementieren ist.

Wie schreibt ihr gute User-Storys?

Eine User-Story darf weder zu allgemein, noch zu detailliert verfasst werden. Ein guter Ansatz ist dabei das von Bill Wake erstellte INVEST-Prinzip:

  • Independent (unabhängig) – Jede User-Story ist unabhängig von anderen. Die Entwicklung kann in beliebiger Reihenfolge stattfinden.
  • Negotiable (verhandelbar) – Nicht zu viele Details. Damit bleiben User-Storys flexibel und veränderbar.
  • Valuable (nützlich) – Anwender und Kunde erhalten einen Mehrwert durch die User-Story.
  • Estimable (schätzbar) – Der Aufwand muss eingeschätzt werden können.

Siehe dazu auch: So funktionieren Story-Points

  • Small (klein) – User-Storys sollten nicht zu komplex werden. Der Aufwand muss gut einschätzbar sein. Außerdem sollte für eine User-Story lediglich eine Iteration benötigt werden.

Was eine Iteration ist, liest du in unserem Scrum-Erklärstück

  • Testable (testbar) – Wann ist eine User-Story abgearbeitet? Akzeptanzkriterien sollten formuliert werden.

All diesen Anforderungen gerecht zu werden, kann im Alltag zur Herausforderung werden. Als gute Faustregel können ein bis zwei Sätze mit anschließenden Akzeptanzkriterien pro User-Story angenommen werden. Helfen können auch Vorlagen, mit denen INVEST schon fast von alleine eingehalten werden kann. Wenn für alle User-Storys die gleiche Vorlage genutzt wird, besteht zudem eine projektweite einheitliche Struktur. Eine solches Muster kann zum Beispiel wie folgt aussehen:

Als [(Anwender-)rolle] möchte ich [Funktionalität/Ziel/Wunsch], damit [Nutzen].

Akzeptanzkriterien:

[Auflistung]

Eine fertige Story-Card könnte am Ende beispielsweise ungefähr so aussehen:

Als Autor möchte ich beim Schließen der Software gefragt werden, ob das aktuelle Dokument gespeichert werden soll, damit keine Änderungen verloren gehen.

Akzeptanzkriterien:

  • Beim Schließen erscheint ein Popup mit einem Hinweistext und drei Buttons zum Abbrechen, Speichern und Nicht speichern
  • Der Button Abbrechen bricht den Schließvorgang ab, ohne das Dokument zu speichern

Auch wenn das „N“ in INVEST vorschreibt, dass User-Storys verhandelbar sein sollten, gilt das nur bedingt für die Akzeptanzkriterien. Die können auch erst gröber als im obigen Beispiel formuliert werden und später an Details zunehmen. Wichtig ist, dass der Product-Owner eine User-Story mithilfe einiger weniger Stichpunkte abnehmen kann. Sie dienen also als Testfälle, die das „T“ in Bill Wakes Merkspruch ermöglicht.

Was ist der Unterschied zwischen einem Use-Case und einer User-Story?

Zu agilen Methoden gehören häufig auch Use-Cases – eine Beschreibung, wie Anwender mit einem System interagieren, wenn sie ein bestimmtes Ziel erreichen wollen. Die Begriffe Use-Case und User-Story müssen aber klar voneinander getrennt werden. Use-Cases beschreiben zum Erreichen des Ziels den Vorgang im gesamten Kontext und sind damit häufig komplexer. Sie werden über das ganze Projekt gepflegt und haben entsprechend meist über die komplette Projektdauer ihre Gültigkeit. User-Storys hingegen sind deutlich knapper formuliert, damit sie auch in einer Iteration abgeschlossen werden können. Um einen Use-Case komplett abbilden zu können, gehen daraus auch meist mehrere User-Storys hervor.

Weitere Erklärstücke zum Thema Scrum:

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung