Anzeige
Anzeige
Ratgeber
Artikel merken

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

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.

Von Andreas Domin
3 Min. Lesezeit
Anzeige
Anzeige

(Foto: Shutterstock)

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?

Anzeige
Anzeige

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.

Anzeige
Anzeige

Du möchtest Scrum besser kennenlernen und verstehen? Unsere Videokurse zeigen dir, wie es geht!

Anzeige
Anzeige

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:

Anzeige
Anzeige

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.

Anzeige
Anzeige

Weitere Erklärstücke zum Thema Scrum:

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
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

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

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

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

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

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige