User Stories schreiben - Praktischer Guide

🍕

FoodExpress

Unsere fiktive Lieferdienst-App als durchgängiges Beispiel. Kunden bestellen Essen, Restaurants bereiten zu, Fahrer liefern aus.

👤 Kunde 👨‍🍳 Restaurant 🚴 Fahrer 👩‍💼 Support

📝 Das User Story Format

Als [Rolle]
möchte ich [Funktion]
damit [Nutzen]

WER?

Welcher Benutzertyp?

WAS?

Welche Funktion?

WARUM?

Welcher Mehrwert?

💡 Warum dieses Format?

Das Format zwingt uns, aus Nutzersicht zu denken. Wir beschreiben NICHT die technische Lösung, sondern das Problem und den gewünschten Nutzen. Das Team entscheidet dann WIE es umgesetzt wird.

✅ INVEST-Kriterien

Gute User Stories erfüllen diese 6 Kriterien. Klicke auf jedes für Details:

Independent

Stories sollten unabhängig voneinander umsetzbar sein. Keine Story sollte blockiert sein, weil eine andere noch nicht fertig ist. Tipp: Wenn Stories stark abhängig sind, kombiniere sie oder schneide sie anders.

Negotiable

Stories sind keine Verträge! Sie sind Platzhalter für Gespräche. Die Details werden im Refinement und Sprint Planning besprochen. Die Story beschreibt das WAS, das Team entscheidet das WIE.

Valuable

Jede Story muss Wert für den Nutzer oder das Business liefern. Rein technische Tasks sind KEINE User Stories! Frage: Würde ein Kunde dafür bezahlen? Wenn nein, ist es vielleicht keine Story.

Estimable

Das Team muss den Aufwand schätzen können. Wenn nicht, ist die Story zu unklar oder zu groß. Lösung: Im Refinement klären oder in kleinere Stories aufteilen (Splitting).

Small

Stories sollten klein genug sein, um in einem Sprint fertig zu werden. Idealerweise mehrere Stories pro Sprint. Faustregel: Wenn eine Story > 50% der Sprint-Kapazität braucht, ist sie zu groß.

Testable

Es muss klar sein, wie man prüft ob die Story erfüllt ist. Dafür gibt es Akzeptanzkriterien! Wenn du nicht beschreiben kannst wie du testest, ist die Story nicht klar genug definiert.

☑️ Akzeptanzkriterien

📋 Was sind Akzeptanzkriterien?

Akzeptanzkriterien definieren die Bedingungen, die erfüllt sein müssen, damit eine Story als "fertig" gilt. Sie sind der Vertrag zwischen Product Owner und Team.

Akzeptanzkriterien	Definition of Done
Pro Story unterschiedlich	Für ALLE Stories gleich
Vom Product Owner definiert	Vom Team/Organisation definiert
Beschreibt WAS die Story erfüllen muss	Beschreibt Qualitätsstandards
Beispiel: "Nutzer kann mit PayPal zahlen"	Beispiel: "Code reviewed, Tests bestanden"

🍕 FoodExpress Beispiele

✓ Gut Bestellstatus verfolgen ▼

Als Kunde möchte ich den Status meiner Bestellung in Echtzeit sehen, damit ich weiß, wann mein Essen ankommt.

Akzeptanzkriterien:

Status zeigt: Bestellt → In Zubereitung → Unterwegs → Geliefert
Push-Benachrichtigung bei jedem Statuswechsel
Geschätzte Ankunftszeit wird angezeigt
Karte zeigt Fahrer-Position (wenn "Unterwegs")

✅ Warum ist das gut?

Klare Rolle (Kunde), konkreter Nutzen (wissen wann Essen kommt), testbare Kriterien, liefert echten Wert.

✓ Gut Bestellung stornieren ▼

Als Kunde möchte ich meine Bestellung stornieren können, solange sie noch nicht in Zubereitung ist, damit ich flexibel bleibe.

Akzeptanzkriterien:

Storno-Button sichtbar wenn Status = "Bestellt"
Storno-Button verschwindet bei Status = "In Zubereitung"
Bestätigung vor Stornierung
Vollständige Rückerstattung innerhalb 24h
Bestätigungs-E-Mail an Kunde

✅ Warum ist das gut?

Enthält wichtige Geschäftsregel (nur vor Zubereitung), klare Edge Cases, messbare Kriterien (24h).

✓ Gut Restaurant: Bestellung annehmen ▼

Als Restaurant-Mitarbeiter möchte ich neue Bestellungen mit einem Klick annehmen können, damit ich schnell reagieren kann und der Kunde informiert wird.

Akzeptanzkriterien:

Akustisches Signal bei neuer Bestellung
Bestellung zeigt alle Details (Artikel, Extras, Adresse)
Ein Klick auf "Annehmen" setzt Status auf "In Zubereitung"
Geschätzte Zubereitungszeit muss angegeben werden

✗ Schlecht Datenbank optimieren ▼

Als Entwickler möchte ich die Datenbank-Queries optimieren.

❌ Was ist falsch?

Kein Nutzen für den Endanwender (WARUM fehlt)
"Entwickler" ist keine echte Benutzerrolle
Technische Aufgabe, keine User Story
Besser als Technical Task im Sprint Backlog

✗ Schlecht Login implementieren ▼

Als Benutzer möchte ich mich einloggen können.

❌ Was ist falsch?

Kein Nutzen angegeben (WARUM?)
"Benutzer" ist zu unspezifisch - welche Rolle?
Keine Akzeptanzkriterien
Zu groß - wie genau? E-Mail? Social Login?

✅ Besser so:

Als wiederkehrender Kunde möchte ich mich mit meiner E-Mail anmelden können, damit meine Lieferadressen und Zahlungsmethoden gespeichert sind.

✗ Schlecht Komplettes Bestellsystem ▼

Als Kunde möchte ich Essen bestellen, bezahlen, verfolgen und bewerten können.

❌ Was ist falsch?

EPIC, keine User Story - viel zu groß!
Enthält mindestens 4 separate Stories
Nicht in einem Sprint umsetzbar
Nicht schätzbar

✅ Aufteilen in:

Story 1: Restaurant-Menü durchsuchen
Story 2: Artikel in Warenkorb legen
Story 3: Mit Kreditkarte bezahlen
Story 4: Bestellstatus verfolgen
Story 5: Bestellung bewerten

💡 Praktische Tipps

1️⃣ Nutzer, nicht System

Schreibe aus Nutzersicht, nicht aus Systemsicht. Nicht "Das System soll...", sondern "Als Kunde möchte ich...".

2️⃣ Vertikal schneiden

Schneide durch alle Schichten (UI, Backend, DB) statt horizontal. Jede Story liefert sichtbaren Wert.

3️⃣ WARUM ist entscheidend

Der "damit"-Teil ist der wichtigste! Wenn du keinen Nutzen formulieren kannst, hinterfrage ob die Story wirklich gebraucht wird.

4️⃣ 3-5 Akzeptanzkriterien

Weniger als 3: wahrscheinlich unklar. Mehr als 7: Story zu groß, aufteilen!

5️⃣ Spezifische Rollen

Vermeide "Als Benutzer". Nutze konkrete Rollen: Neukunde, wiederkehrender Kunde, Restaurant-Manager, Fahrer.

6️⃣ Conversation Starter

User Stories sind kein Lastenheft! Sie sind Einladungen zum Gespräch. Die Details klären sich im Refinement.