Wie man gute User Stories schreibt: Ein Leitfaden für Product Owner und Stakeholder

Was macht eine gute User Story aus?

Eine gut formulierte User Story besteht aus zwei zentralen Elementen:

1. Einer prägnanten Beschreibung des Ziels

2. Einer klaren und messbaren Reihe von Akzeptanzkriterien

Ein beliebtes Template für User Stories dient als guter Ausgangspunkt:

Als [Persona] möchte ich [Benutzeraktion], damit [erwartetes Ergebnis].

Lassen wir uns das genauer anschauen:

• Als [Persona]: Dies repräsentiert die Benutzerrolle. Bevor User Stories geschrieben werden, sollten Personas definiert werden, um ein besseres Verständnis für die Nutzer und ihre Bedürfnisse zu gewinnen. Eine Persona kann beispielsweise ein „neuer Kunde“ oder ein „Systemadministrator“ sein.

• Ich möchte [Benutzeraktion]: Dies beschreibt die spezifische Handlung des Nutzers in einem bestimmten Moment. Zum Beispiel: „Ich möchte ein Produkt in meinen Warenkorb legen.“

• Damit [erwartetes Ergebnis]: Dieser Teil beantwortet das „Warum“ der Story. Er verdeutlicht den Nutzen oder die Erwartung hinter der Handlung des Nutzers und sorgt dafür, dass das Team den Zweck der Story versteht. Zum Beispiel: „Damit ich meinen Einkauf abschließen und meine Artikel schnell erhalten kann.“

Eine User Story ist mehr als eine einfache Aufgabe. Sie beschreibt die Situation eines Nutzers, seine Handlung und das gewünschte Ergebnis. Dieser Kontext hilft dem Team, sich in den Nutzer hineinzuversetzen und bessere Lösungen zu entwickeln.

Häufige Fehler beim Schreiben von User Stories

Viele Product Owner und Stakeholder machen typische Fehler bei der Erstellung von User Stories:

1. Unklare Personas: Wenn lediglich „als Nutzer“ geschrieben wird, fehlt die Spezifik. Dadurch entstehen generische Stories, die nicht wirklich auf die Bedürfnisse der Benutzer eingehen.

2. Fehlender Mehrwert: Wird der „damit“-Teil weggelassen, bleibt der Nutzen der Story unklar.

3. Zu viele Details: Wenn User Stories wie kleine Spezifikationsdokumente geschrieben werden, verlieren sie ihren Fokus auf das eigentliche Ziel.

4. Fehlende Akzeptanzkriterien: Ohne klare Akzeptanzkriterien ist unklar, wann eine Story als abgeschlossen gilt und wie sie getestet werden kann.

5. Unzureichend vorbereitete Stories: Wenn Entwicklern Stories zugewiesen werden, ohne dass notwendige Vorarbeiten wie UI-Designs, Logikprüfungen oder technische Machbarkeiten geprüft wurden, müssen sie Grundsatzfragen klären, anstatt sich auf die Umsetzung zu konzentrieren.

Wie schreibt man klare und effektive User Stories?

Schritt 1: Personas definieren

Bevor User Stories geschrieben werden, sollten klare Personas erstellt werden. Eine Persona ist eine fiktive Darstellung eines typischen Nutzers mit seinen Zielen, Verhaltensweisen und Herausforderungen.

Beispiel:

• Name: Emily, die neue Kundin

• Ziel: Einfach online einkaufen können

• Herausforderung: Frustration über komplizierte Checkout-Prozesse

Schritt 2: Das User Story-Template nutzen

Das „Als … möchte ich … damit …“-Format sorgt für klare, verständliche Stories:

• Persona: Wer nutzt die Funktion?

• Aktion: Was tut der Nutzer?

• Mehrwert: Warum ist diese Story wichtig?

Beispiel:

Als wiederkehrender Kunde möchte ich meine Zahlungsdetails speichern, damit ich zukünftige Einkäufe schneller abschließen kann.

Schritt 3: Den Umfang begrenzen und Feedback einholen

User Stories sollten klein, fokussiert und inkrementell sein:

• Akzeptanzkriterien begrenzen: Eine gute Story hat in der Regel drei bis fünf Akzeptanzkriterien. Sind es mehr, sollte sie in kleinere Stories aufgeteilt werden.

• Feedback einholen: Nach der Implementierung einer Story sollte Nutzerfeedback gesammelt werden, um Folge-Stories oder Verbesserungen zu definieren.

Starke Akzeptanzkriterien schreiben

Akzeptanzkriterien sind essenziell, um sicherzustellen, dass alle Beteiligten ein gemeinsames Verständnis darüber haben, wann eine Story als abgeschlossen gilt.

1. Traditionelle Akzeptanzkriterien

Eine klare Liste von Bedingungen, die erfüllt sein müssen:

• Der Nutzer muss Zahlungsdetails sicher speichern können.

• Die gespeicherten Zahlungsdetails sollen beim Checkout automatisch ausgefüllt werden.

• Der Nutzer muss gespeicherte Zahlungsmethoden entfernen oder aktualisieren können.

2. Szenario-basierte Kriterien mit Gherkin

Das Gherkin-Format bietet eine strukturierte Möglichkeit, Testszenarien zu formulieren:

• Given (Gegeben): Ausgangssituation

• When (Wenn): Handlung

• Then (Dann): Erwartetes Ergebnis

Beispiel:

Given ein Kunde mit einer gespeicherten Zahlungsmethode
When er den Checkout-Prozess durchläuft
Then sollte seine Zahlungsmethode automatisch ausgefüllt werden

‍

Der Vorteil von Gherkin liegt in der Automatisierung. Tools wie Cypress ermöglichen es, Tests direkt aus diesen Szenarien abzuleiten, wodurch die Teststrategie optimiert wird.

Vermeidung unzureichend vorbereiteter Stories

Ein häufiger Fehler in agilen Projekten ist es, mit der Entwicklung zu beginnen, bevor die Stories vollständig vorbereitet sind. Bevor eine Story an die Entwickler übergeben wird, sollten alle notwendigen Anforderungen klar sein. Beispielsweise sollte das UI-Design für responsive Anwendungen bereits fertiggestellt und für alle relevanten Geräte optimiert sein.

Wichtige Kriterien für gut vorbereitete Stories:

1. Notwendige Anforderungen: Alle essenziellen Aspekte (z. B. Barrierefreiheit, Sicherheit) müssen definiert sein, wenn sie für die Story relevant sind.

2. Logische Validierung: Die Story-Logik muss realistisch und mit der Systemarchitektur kompatibel sein.

3. Klarheit: Unklare Anforderungen oder offene Fragen sollten vor der Entwicklung geklärt werden.

Wenn diese Schritte übersprungen werden, müssen Entwickler während der Umsetzung grundlegende Fragen klären, was zu Verzögerungen, Frustration und ineffizienten Lösungen führt.

Best Practices für das Schreiben von User Stories

1. Zusammenarbeit mit dem Team: Entwickler, Tester und Designer sollten frühzeitig in die Definition und Verfeinerung der Stories eingebunden werden, um realistische und testbare Stories zu gewährleisten.

2. Fokus auf den Mehrwert: Jede Story sollte eine klare Antwort auf die Frage „Warum setzen wir das um?“ liefern. Wenn der Mehrwert nicht ersichtlich ist, sollte die Story überdacht werden.

3. Einfach halten: Stories sollten keine technischen Spezifikationen enthalten. Detaillierte technische Anforderungen sollten in separaten Dokumenten festgehalten werden.

4. Iteratives Vorgehen: User Stories sollten regelmäßig überprüft und verbessert werden, um aus gewonnenen Erkenntnissen zu lernen.

5. Automatisierung nutzen: Szenario-basierte Akzeptanzkriterien können mit Tools wie Gherkin und Cypress automatisiert werden, um sicherzustellen, dass Stories korrekt umgesetzt werden.

Fazit: Die Kunst des Schreibens großartiger User Stories

Ein großes Problem in der agilen Entwicklung ist es, mit der Implementierung von User Stories zu beginnen, die nicht ausreichend durchdacht sind. Bevor eine Story einem Entwickler zugewiesen wird, sollten bestimmte Kriterien erfüllt sein.

• Alle notwendigen Vorbereitungen abgeschlossen: UI-Designs, Geschäftslogik oder API-Endpunkte sollten bereits bereitstehen.

• Logische Validierung sichergestellt: Die Story sollte technisch machbar und mit der bestehenden Architektur kompatibel sein.

• Klare Anforderungen ohne offene Fragen: Entwickler sollten alle wichtigen Informationen vorliegen haben, um sich auf die Umsetzung konzentrieren zu können.

Wenn diese Punkte nicht beachtet werden, müssen Entwickler Lücken selbst füllen, was zu Missverständnissen, Mehraufwand und ineffizienten Lösungen führt.

Schlecht formulierte User Stories haben weitreichende Konsequenzen. Unklare oder unvollständige Anforderungen führen dazu, dass Entwickler wertvolle Zeit mit Fehlinterpretationen oder Korrekturen verbringen. Funktionen können dadurch von den eigentlichen Geschäftsanforderungen abweichen, was Frustration bei Stakeholdern und Nutzern hervorruft. Klare, gut durchdachte User Stories sind daher essenziell für den Erfolg eines agilen Entwicklungsprozesses.

‍