METHODE

User Story

Eine kurze Beschreibung eines Features aus Sicht des Nutzers, in der Form 'Als [Rolle] möchte ich [Ziel], damit [Nutzen]', die die Absicht erfasst statt einer technischen Spezifikation.

Zuletzt geprüft: 2026-06-02 vonKevin Riedl wiki ↗

Eine User Story erfasst ein Stück Wert aus der Perspektive der Person, die es will, meist im Format “Als [Rolle] möchte ich [Ziel], damit [Nutzen]”. Das Format ist keine Bürokratie um ihrer selbst willen. Das “Als” zwingt euch, zu benennen, wer das tatsächlich will, und das “damit” zwingt euch, das Warum zu nennen, also den Teil, den Teams überspringen und dann das Falsche bauen. Eine Story ist ein Platzhalter für ein Gespräch, kein Vertrag.

Gute Stories erfüllen meist die INVEST-Kriterien: Independent (eigenständig baubar), Negotiable (die Details bleiben offen, bis ihr sie besprecht), Valuable (liefert etwas, das einem Nutzer oder Käufer wichtig ist), Estimable (das Team kann sie schätzen), Small (passt in eine Iteration) und Testable (man kann erkennen, wann sie fertig ist). An den letzten beiden scheitern die meisten Stories: zu groß zum Fertigstellen oder so vage geschrieben, dass niemand sagen kann, was “fertig” bedeutet.

Akzeptanzkriterien sind, wie eine Story testbar wird. Sie sind die konkreten Bedingungen, die gelten müssen, damit die Story angenommen wird, geschrieben bevor die Arbeit beginnt. “Als Nutzer möchte ich mein Passwort zurücksetzen” ist eine Absicht. Die Akzeptanzkriterien (ein Reset-Link verfällt nach einer Stunde, ein ungültiges Token zeigt einen klaren Fehler, ein erfolgreiches Zurücksetzen meldet den Nutzer an) sind das, wogegen das Team tatsächlich baut und testet.

Das häufige Anti-Pattern ist die Story, die eine verkleidete Aufgabe ist. “Als Entwickler möchte ich einen Index auf der Orders-Tabelle hinzufügen” trägt das User-Story-Kostüm, aber es gibt keinen Nutzer und keinen Nutzen, nur eine technische Aufgabe mit Hut. Das zu tracken ist in Ordnung, aber es ist keine User Story, und technische Aufgaben als Stories zu verkleiden löscht still die Nutzerperspektive, zu deren Schutz das Format existiert."

// FAQ

Häufige Fragen

Häufige Fragen

Eine kurze Beschreibung eines Features aus Sicht des Nutzers, meist ‘Als [Rolle] möchte ich [Ziel], damit [Nutzen]’. Sie erfasst, wer etwas will und warum, und dient als Platzhalter für ein Gespräch statt als vollständige technische Spezifikation.
Eine Checkliste für eine gute Story: Independent, Negotiable, Valuable, Estimable, Small und Testable. Die meisten Stories scheitern an Small (zu groß für eine Iteration) oder Testable (zu vage, um fertig zu definieren). Die Kriterien sind ein schneller Weg, problematische Stories zu erkennen, bevor sich das Team festlegt.
Wenn sie eine verkleidete technische Aufgabe ist. ‘Als Entwickler möchte ich einen Datenbankindex hinzufügen’ hat keinen echten Nutzer und keinen Nutzen, nur eine technische Aufgabe im Kostüm. Solche Arbeit zu tracken ist in Ordnung, aber sie eine User Story zu nennen löscht die Nutzerperspektive, zu deren Schutz das Format existiert, und das untergräbt den Sinn.