ScrumSo erstellen Sie gute User Stories

Product Owner formulieren in User Stories die Wünsche der Anwender für Software oder andere Leistungen. Wie werden User Stories richtig formuliert?

User Stories sind das wichtigste Werkzeug, um agile Projekte inhaltlich zu steuern. Mit User Stories werden die Anforderungen der Kunden an ein Softwareprodukt oder an eine Geschäftslösung beschrieben. Die Entwickler erfahren durch die User Stories, was genau der Auftraggeber oder Nutzer will und warum er das will.

Was sind User Stories?

User Stories sind Nutzergeschichten. Der Product Owner beschreibt in einer User Story die Anforderungen aus Nutzersicht: Wie wünschen sich Anwender eine Software oder Kunden einen Liefergegenstand, um ihre Geschäftsziele zu erreichen.

Obwohl der Begriff „User Story“ im Scrum Guide nicht auftaucht, nutzen agile Arbeitstechniken ihn häufig. User Stories stehen im Backlog neben Epics und Tasks, Qualitätsanforderungen, Fehlern und Verbesserungen. User Stories bestehen aus wenigen, leicht verständlichen Sätzen. Sie sind kurz, aus Kundensicht jedoch spezifisch und detailliert.

User Stories transportieren nicht nur Erwartungen an zukünftige IT-Systeme, sondern auch Anforderungen an Liefergegenstände, die agile Projekte realisieren. User Stories bewegen sich im Anforderungsraum, ohne in den Lösungsraum zu wechseln. Sie geben keine technischen Lösungen vor, die die Entwickler zum sturen Realisieren zwingen.

Beispiele für User Stories:

  • Ein neuer Kunde soll sich bei einem E-Learning-Portal registrieren, um sich auf eine Zertifizierung vorzubereiten.
  • Ein Kunde möchte Waren in einem Webshop auswählen und dann bestellen.
  • Ein IT-Administrator möchte Datenbanken verwalten, indem er Datensätze anlegt, ändert oder löscht.
  • Eine Abteilung in einem internationalen Konzern soll in einen neuen Bereich und damit in eine neue Struktur überführt werden.

Epic, Story und Task

Die folgende Grafik illustriert den Zusammenhang zwischen Epics, Stories und Tasks.

© KAYENTA Training und Beratung

Epic

Epic ist eine User Story auf höchster Abstraktionsstufe. Für einen Sprint ist sie zu groß. Der Product Owner zerlegt sie deshalb in mehrere kleinere User Stories.

Story

Die Story ist eine User Story und Teil einer Epic. Eine Story enhält die Anforderungen, geschrieben als kleine handhabbare Texte. Auf dieser Basis schätzt das Team den Realisierungsaufwand ein.

Task

Entwickler und Tester zerlegen eine Story in einzelne Aufgaben (Tasks). Wenn eine Aufgabe eine vereinbarte Zeitspanne überschreitet, kann sie in zusätzliche Aufgaben aufgeteilt werden. Eine Story ist dann erledigt, wenn alle Aufgaben der Story erledigt sind.

Wie sollte eine User Story formuliert sein?

Eine User Story sollte einfach und leicht verständlich sein. Das gelingt mit einfachen Satzkonstruktionen: Subjekt, Verb, Objekt. Mehrdeutige Begriffe gehören nicht in eine User Story.

Die User Story soll sich auch auf das Wesentliche konzentrieren. Rachel Davie, Co-Autorin des Buchs „Agile Coaching“, empfiehlt die Formulierung der User Story nach folgendem Muster:

„Als [Rolle] möchte ich [Funktion] um [Nutzen].“

Dabei ergeben sich Rolle, Funktion und Nutzen aus den Antworten auf die folgenden W-Fragen:

Wer fordert etwas an? (=Rolle)

Der Anforderer ist meist der spätere Nutzer des Systems oder der Nutznießer der zu entwickelnden Lösung.

Was wünscht sich der Anforderer? (=Funktion)

Der Anforderer wünscht sich, dass etwas bestimmtes passiert. Je klarer und präziser der Wunsch in die User Story eingeht, desto hilfreicher ist die User Story für das Entwicklertteam, um die Anforderungen zu realisieren.

Warum ist das für den Geschäftsfall wichtig? (=Nutzen)

Durch die Anforderung soll ein Ziel erreicht werden. Der Anforderer verspricht sich davon einen Nutzen. Die Beschreibung des Grundes der Anforderung liefert dem Entwicklerteam weitere Informationen zur richtigen Ausführung.

Beispiel für die Formulierung einer User Story

Ein E-Learning-Portal, das Seminare für Projektleiter anbietet, könnte für die Registrierung eines neuen Kunden diese User Story texten:

„Als Neukunde möchte ich mich im E-Learning Portal registrieren, um mich auf die PMI-Zertifizierung vorzubereiten.“

Woran lässt sich erkennen, ob eine User Story gut ist?

Mit den „INVEST“ Kriterien erkennt der Product Owner, ob die User Story gut ist.

Independent (unabhängig)

Jede einzelne Geschichte sollte unabhängig von anderen User Stories sein. Die Umsetzung einer Story darf nicht voraussetzen, dass vorher eine andere Story umgesetzt wurde.

Negotiable (verhandelbar)

User Stories sind keine unumstößlichen Vertragstexte. Product Owner, Stakeholder und das Entwicklerteam diskutieren und präzisieren die User Stories gemeinsam, um ein optimales Verständnis zu erzielen.

Valuable (nützlich)

Das Ergebnis der Story muss für den Anwender sinnvoll sein und Wert stiften.

Estimable (schätzbar)

Das Entwickerteam muss in der Lage sein, Aufwände für die Realisierung abschätzen zu können.

Small (klein)

Der Umfang der User Story sollte angemessen sein, das heißt, sie sollte in einem Sprint realisierbar sein.

Testable (testbar)

Jede User Story muss getestet werden können. Mit dem Test wird die erfolgreiche Umsetzung der User Story festgestellt.

Die Story Card

Es bleibt dem Product Owner überlassen, wie er User Stories erfasst und verwaltet. Der Scrum Guide schreibt ihm nichts vor. In der Praxis hat es sich jedoch als sinnvoll erwiesen, die User Story auf eine Story Card zu notieren.

© KAYENTA Training und Beratung

Card, Conversation, Confirmation

Neben den „INVEST“-Kriterien gibt es noch andere Regeln bei der Erstellung von User Stories. Ron Jeffries nennt drei kritische Aspekte, die beim Erstellen von User Stories beachtet werden sollten: Card, Conversation und Confirmation.

Card

Geschichten werden traditionell auf Karten geschrieben. Deshalb sollten sich Product Owner kurz fassen und nicht mehr Platz verbrauchen als die Karte es zulässt.

Conversation

Anforderungen sollten dem Entwicklerteam nicht „über den Zaun“ geworfen werden. Auftraggeber und Entwickler sollten miteinander über die Karten sprechen, um so das Verständnis aller Beteiligten zu schärfen. Denn der Teufel steckt im Detail. Erst im Gespräch zeigt sich, ob den Entwicklern wirklich klar ist, was sie bauen sollen.

Confirmation

Eine User Story ist dann abgeschlossen, wenn die Akzeptanzkriterien erfüllt sind. Sie beschreiben, was von der Story erwartet wird, um sie als „fertig“ zu melden. Akzeptanzkriterien sind flexibel und werden bei Bedarf angepasst, bis das Team mit der Realisierung der User Story startet. Scrum Master und Entwicklerteam klären in Gesprächen, ob ein gemeinsames Verständnis besteht. So werden Missverständnisse vermieden, die im Nachgang zeitfressend ausgeräumt werden müssten.

Was tun, wenn die User Story zu groß ist?

Sind User Stories zu umfangreich, kann das Team den Aufwand kaum verlässlich abschätzen. Deshalb spaltet der Product Owner die Anforderungen in kleinere Einheiten. Wie geht er dabei am besten vor, ohne wertvolle Informationen zu verlieren?

User Story vertikal formulieren

User Stories sollten vertikal formuliert werden. Das heißt: Unterschiedliche Bereiche eines technischen Systems, wie zum Beispiel Frontend und Backend, adressieren. Am Ende eines Sprints sollte dem Kunden eine Funktionalität zur Verfügung stehen, die vollständig nutzbar ist.

„INVEST“ Ansatz beachten

Prüfen, ob die User Stories dem „INVEST“ Ansatz entsprechen.

Sich auf den größten Nutzen konzentrieren

Besitzt die Anforderung einen simplen Kern? Verspricht dieser den größten Nutzen für den Geschäftsablauf? Nach Geschäftsfällen ordnen und sich auf die mit dem größten Nutzen fokussieren.

Komplexität verringern

Optionen und Komplexität sollten verringert werden. Wenn der Anwender zum Beispiel keine komplexe Oberfläche benötigt, ist es vielleicht möglich, mit einem schlichten und einfachen Design zu starten.

User Story aufsplitten

Umfangreiche User Stories sollten nach Funktionen, Aktionen oder Operationen aufgesplittet werden, die der Benutzer separat ausführen kann.

Dazu im Management-Handbuch

Ähnliche Artikel

Gesundheitstipps