User Stories sind in vielen Unternehmen ein Thema, wenn diese mit agilen Entwicklungsmethoden (Scrum oder Kanban) ein Produkt oder Projekt entwickeln möchten. Spätestens dann entstehen Unklarheiten und Fragen zur User-Story wie: “Was eine User-Story ist?”, “Was muss drinnen stehen?” und “Wie umfangreich sollten die Details sein?”. Für User-Stories gibt es in der Regel kein festes Format, deswegen erfahrt ihr in diesem Artikel kurz das Wichtigste zur User Story.
Definition einer User-Story
Die User-Story beschreibt eine (1) Funktionalität, die für den Kunden / dem Anwender eines Produkts oder Service nützlich ist. Sie wird schriftlich festgehalten und beschreibt die Funktionalität und Akzeptanzkriterien, die festlegen wann die User-Story vollständig umgesetzt ist.
3 Bestandteile einer User-Story
Eine User-Story setzt sich also aus 3 Bestandteilen zusammen:
- Die schriftliche Beschreibung der Funktionalität zur Planung der Umsetzung.
- Gespräche zur Story, um die Details der Funktion herausarbeiten zu können.
- Tests / Akzeptanszkriterien die dabei helfen festzulegen, wann die Story erfolgreich umgesetzt wurde.
Aufbau der User-Story
Der Aufbau einer User-Story sieht in der Regel so aus:
Als <Anwendertyp>, möchte ich <Ziel / Wunsch> erreichen, aus folgenden Gründen <Nutzen>.
<Anwendertyp>steht für eine Benutzerrolle (oder dem Kunden), für die eine Funktionalität gefordert wird. Man kann auch Personen anstelle von Benutzerrollen einsetzen.<Ziel / Wunsch>enthält eine Beschreibung der Funktionalität oder Eigenschaft, die das Produkt oder der Service bereitstellen soll und warum dieser nützlich ist. Details hierzu werden in nachfolgenden Gesprächen erarbeitet.- Der
<Nutzen>liefert die Motivation für die User-Story (Grundlage für die Priorisierung). Hier wird anhand von Akzeptanzkriterien / Tests dokumentiert wann die Story vollständig umgesetzt ist.
Infos zu den Akzeptanzkriterien / Tests: Damit sowohl der Produkt Owner als auch das umsetztende Entwicklerteam eine Basis haben, wann eine User-Story Funktionalität als vollständig angesehen werden kann, also abgenommen werden kann, sind Details zu den Akzeptanzkriterien oder Abnahmetests nötig. Beispielsweise nach dem Given-When-Then-Schema.
Infos zum “Given-When-Then-Schema”: Für jede Aktion des Anwenders wird nach diesem Schema eine Reaktion im Erfolgs- oder Fehlerfall beschrieben.
“Given” Angenommen es gelten die folgenden Voraussetzungen, “when” wenn der Benutzer eine oder mehrere Aktionen durchführt, “then” dann folgt folgende Reaktion der Anwendung / des Service.
Beispiel für “Given-When-Then-Schema”
Der Anwender möchte über das Suchfeld nach einem bestimmten Download-Dokument (Name oder Teile eines Namens) suchen, wird etwas gefunden, wird ein Suchergebnis ausgegeben.
- Das Suchergebnis gibt maximal 20 Dokumente pro Bildschirmseite aus.
- Werden mehr als 20 Dokumententitel gefunden kann der Anwender über eine Navigation am Seitenende zwischen den Ergebnissen navigieren.
- Die Suche dauert nicht länger als 5 Sekunden.
- Wird nichts gefunden, wird der Anwender darüber informiert.
Beispiele für User-Stories
Ein akzeptables Beispiel für eine Funktionalität, die in einer User-Story beschrieben wird wäre folgendes:
Neuen Download starten: Als registrierter Anwender möchte ich nach dem Login am System meine neu zur Verfügung stehenden Downloads an oberster Stelle sehen. Das spart Zeit.
Ein unnützes Beispiel für eine User-Story, weil Sie für den Anwender keinen Mehrwert hat wäre folgende User-Story (weil dem Anwender egal ist, mit welcher Programmiersprache das System geschrieben wird):
Verwendetes Framework: Als Basis wird Drupal eingesetzt und die Entwickler müssen PHP können.
Wer schreibt eine User-Story und wo?
Jeder kann eine User-Story schreiben. Der Kunde, der Product Owner, der Anwender, der Entwickler, der Designer, der Administrator etc. Je nachdem welche Tools zum Einsatz kommen (z.B. Redmine oder Jira) werden User-Stories in Ticketsystemen (oft im sogenannten “Backlog”) verwaltet, oder auf Post-It-Notes oder auch Karteikärtchen festgehalten.
Sie können prinzipiell in beliebiger Form dokumentiert werden. Wichtig ist nur, dass Sie für alle leicht zugänglich und ersichtlich sind und einfach umorganisiert und priorisiert werden können.
Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung.