Was ist eine User Story?

Eine User Story ist eine kurze, informelle Beschreibung einer Funktion aus Nutzersicht. Sie folgt dem Format: “Als [Rolle] möchte ich [Funktion], damit [Nutzen].”

Tipp: User Stories sind Platzhalter für Gespräche, nicht fertige Spezifikationen. Die Details entstehen im Dialog zwischen Product Owner und Team.

Das User-Story-Format verstehen

Das klassische Format besteht aus drei Teilen:

Rolle — Wer profitiert von dieser Funktion? (“Als Kunde”, “Als Admin”, “Als neuer Nutzer”)

Funktion — Was soll ermöglicht werden? (“möchte ich meine Bestellung verfolgen”)

Nutzen — Warum ist das wichtig? (“damit ich weiß, wann mein Paket ankommt”)

Die drei C’s

Card — User Stories passen auf eine Karteikarte. Diese Beschränkung zwingt zur Fokussierung.

Conversation — Die Story ist ein Gesprächsstarter, kein fertiges Dokument. Details werden im Refinement geklärt.

Confirmation — Akzeptanzkriterien bestätigen, wann die Story erfüllt ist.

INVEST-Kriterien

Gute User Stories sind:

• Independent — Unabhängig von anderen Stories
• Negotiable — Verhandelbar im Detail
• Valuable — Wertvoll für Nutzer oder Geschäft
• Estimable — Schätzbar in Aufwand
• Small — Klein genug für einen Sprint
• Testable — Testbar durch klare Kriterien

Akzeptanzkriterien

Akzeptanzkriterien definieren, wann eine Story “fertig” ist. Das gängigste Format ist Given-When-Then:

• Given (Gegeben) — Ausgangszustand
• When (Wenn) — Aktion des Nutzers
• Then (Dann) — Erwartetes Ergebnis

Beispiel:

Given: Ich bin eingeloggt und habe eine Bestellung When: Ich klicke auf “Bestellung verfolgen” Then: Sehe ich den aktuellen Lieferstatus

User Story vs. Task

Wann sind User Stories die richtige Wahl?

User Stories eignen sich besonders für:

• Produktentwicklung mit unklaren Anforderungen
• Scrum-Teams und agile Umgebungen
• Nutzerzentrierte Entwicklung
• Iterative Verfeinerung von Anforderungen

Für komplexe Systemintegrationen oder regulierte Umgebungen können detailliertere Formate wie Use Cases ergänzend sinnvoll sein.