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

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.

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.

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

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:

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

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.

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:

• Was sind eigentlich Story-Points und wie funktionieren sie?
• Wie funktioniert ein Estimation Game?
• Was ist eine Story-Map?