ScrumSo erstellen Sie gute User Stories

Product Owner formulieren in User Stories die Wünsche der Anwender für Software oder andere Leistungen. Wie formuliert man sie, damit sie eindeutig sind und selbst Laien sie verstehen?

Eine User Story ist das wichtigste Werkzeug, um agile Projekte inhaltlich zu steuern. Sie transportiert die Wünsche des Kunden an ein Softwareprodukt oder an eine Geschäftslösung.

User Stories sind Nutzergeschichten

User Stories sind Nutzergeschichten. Der Product Owner beschreibt, wie sich Anwender eine Software wünschen oder Kunden einen Liefergegenstand eines agilen Projekts, um ihre Geschäftsziele zu erreichen. Beispiele:

  • 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.

Merkmale von User Stories im agilen Projektmanagement

User Stories lesen sich einfach, denn der Product Owner hat sie in Alltagssprache geschrieben. Was kennzeichnet eine User-Story im agilen Projektmanagement?

  • User Stories stehen neben Epics und Tasks, Qualitätsanforderungen, Fehlern und Verbesserungen im Product Backlog.
  • User Stories transportieren nicht nur Erwartungen an zukünftige IT-Systeme, sondern auch Anforderungen an Liefergegenstände, die agile Projekte realisieren.
  • User Stories bestehen aus wenigen Sätzen. Sie sind kurz, knapp und verständlich, aus Kundensicht jedoch spezifisch und detailliert.
  • 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.
  • Der Fachbegriff „User Story“ taucht im Scrum Guide nicht auf. Somit liegt er außerhalb des Kerns dieser Methode. Agile Arbeitstechniken nutzen sie jedoch häufig.

Der Unterschied zwischen Epic, User Story und Task

Der Product Owner entwickelt aus einer geschäftsbezogenen Vision seine Roadmap, die das agile Projekt abarbeiten wird. Zum Anfang ist es für ihn einfacher, das Große und Ganze zu skizzieren. Die Roadmap zerteilt der Product Owner in mehrere Epics, die wiederum mehrere Anforderungen und User Stories umfassen können.

In einem agilen Framework sind Epics große Arbeitsbereiche. Tasks stellen die kleinste Arbeitseinheit da. Somit könnten agile Anforderungen, die inhaltlich korrespondieren, hierarchisch aufgebaut sein. Damit nähern sie sich dem Prinzip einer russischen Matroschka: ineinander schachtelbare, eiförmige Puppen. Die äußeren nehmen die kleineren in sich auf. Die folgende Grafik illustriert den Zusammenhang zwischen Epics, User Stories und Tasks.

© KAYENTA Training und Beratung

Epic

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

User Story

Eine User Story enhält Anforderungen, geschrieben als kleine handhabbare Texte. Auf dieser Basis schätzt das Team den Realisierungsaufwand ein.

Task

Entwickler und Tester zerlegen User Stories in weitere Aufgaben. Wenn eine Aufgabe eine vereinbarte Zeitspanne überschreitet, kann sie in zusätzliche Aufgaben aufgeteilt werden.

Eine User Story ist dann erledigt, wenn alle beinhaltete Aufgaben erledigt sind.

So sehen prägnante User Stories aus

Wie gelingt es, kurze und aussagekräftige User Stories zu verfassen? Wie sollte der Product Owner vorgehen, um sich auf das Wesentliche zu konzentrieren?

  • User Stories einfach und prägnant für Anwender als Zielgruppe formulieren.
  • Aktiven Schreibstil verwenden und Sätze mit Subjekt, Verb und Objekt konstruieren.
  • Auf das Wesentliche konzentrieren.
  • Verwirrende oder zweideutige Begriffe vermeiden.

Dem Texter geht die Arbeit leichter von der Hand, wenn er beim Schreiben die folgenden W-Fragen beantwortet:

Wer fordert etwas an? (Rolle)

Idealerweise beschreibt der zukünftige Nutzer des Systems oder der Nutznießer der zukünftigen Lösung die Anforderungen. Damit sind Hintergründe und die großen Ziele für den Entwickler transparent.

Was wünscht sich der Anforderer? (Funktion)

Je klarer und präziser der Wunsch in der User Story Platz findet, desto hilfreicher sind die Informationen für das Team, um die Anforderungen zu realisieren.

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

Die Beschreibung des Grundes der Anforderung stellt dem Entwicklerteam weitere Informationen zur Verfügung.

Rachel Davie, Co-Autor des Buchs „Agile Coaching“, empfiehlt diese Struktur:

„Als <Rolle> möchte ich <Funktion> um <Nutzen>.“

Beispiel für die Formulierung einer User Story

Ein E-Learning-Portal für Projektleiter, das Seminare 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.“

In aussagekräftige User Stories „investieren“

Das Akronym „INVEST“ erinnert Product Owner daran, wie sie gute User Stories schreiben können:

Independent (unabhängig)

Jede einzelne Geschichte sollte unabhängig von anderen formuliert werden. So werden Probleme vermieden, wenn sie der Wichtigkeit nach sortiert werden müssen.

Negotiable (verhandelbar)

Einmal formulierte User Stories sind keine unumstößlichen Vertragstexte. Vielmehr dienen sie Product Owner, Stakeholder und Entwicklerteam als Diskussionsgrundlage, 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 Team muss in der Lage sein, Aufwände für die Realisierung schä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)

Jeder User Story muss getestet werden können.

User Story auf eine Story-Card notieren

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

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. Die Karten sollten vielmehr zu Diskussionen anregen, 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 genug, um sich zu ändern, bis das Team mit der Realisierung der User Story startet. Scrum Master und Entwicklerteam klären in Gesprächen, ob 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 schwer oder gar nicht schä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

Cookies helfen uns bei der Bereitstellung unserer Dienste. Durch die Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies setzen. Mehr erfahren
OK