Eine User Story ist eine kurze, leichtgewichtige Beschreibung eines gewünschten Nutzens oder einer Systemfähigkeit aus Sicht eines Nutzers oder Stakeholders. Sie dient in agilen Kontexten vor allem als Ausgangspunkt für Kommunikation, Verfeinerung und Akzeptanzkriterien – nicht als vollständige Spezifikation an sich.
Was ist eine User Story?
User Stories sind kurze Beschreibungen von Anforderungen in agilen Entwicklungsumgebungen. Ein verbreitetes Format lautet:
Als Servicemitarbeiter möchte ich offene Fälle nach Priorität filtern, damit dringende Kundenanfragen zuerst bearbeitet werden.
Das Format ist hilfreich, aber nicht die eigentliche Essenz. Eine gute User Story soll Kommunikation über Bedarf, Nutzen und erwartetes Verhalten auslösen.
Fachliche Grundlage: User Stories als agile Requirements
Lucassen et al. untersuchten die Qualität von User Stories und entwickelten das Quality User Story (QUS) Framework sowie das Werkzeug AQUSA. Die Evaluation umfasste 1.023 User Stories aus 18 Softwareunternehmen. Die Forschung zeigt, dass User Stories Qualitätsprobleme wie Mehrdeutigkeit, schlechte Struktur oder fehlende Atomizität aufweisen können – „kurz“ ist also nicht automatisch „gut“.
User Stories gehören in den größeren Kontext des Requirements Engineering. Sie ersetzen Stakeholderanalyse, Validierung oder fachliche Klärung nicht.
Card, Conversation, Confirmation
Ein bekanntes Denkmodell sind die „3 Cs“:
- Card: Die Story hält die Kernidee kompakt fest.
- Conversation: Details entstehen im Gespräch zwischen Beteiligten.
- Confirmation: Akzeptanzkriterien machen überprüfbar, wann die Story fachlich erfüllt ist.
Wer nur die Card dokumentiert und Conversation sowie Confirmation auslässt, reduziert User Stories auf unvollständige Tickets.
Was macht eine gute User Story aus?
Neben QUS ist in der Praxis das Akronym INVEST verbreitet: Independent, Negotiable, Valuable, Estimable, Small, Testable. Diese Kriterien sind Heuristiken, keine Naturgesetze. Eine Story sollte insbesondere einen erkennbaren Nutzen besitzen, ausreichend klein sein und überprüfbar werden.
Akzeptanzkriterien
Akzeptanzkriterien präzisieren fachlich relevante Bedingungen. Beispiel:
- Filter enthält die Prioritäten „niedrig“, „normal“ und „hoch“.
- Mehrere Prioritäten können gleichzeitig gewählt werden.
- Die Auswahl bleibt während der aktuellen Sitzung erhalten.
Sie helfen Produkt, Entwicklung und Test, dasselbe Verhalten zu verstehen.
User Story vs. Use Case
Eine User Story ist meist kompakter und bewusst unvollständig. Ein Use Case beschreibt typischerweise einen Ablauf zwischen Akteur und System inklusive Alternativen oder Ausnahmen. Für komplexe Geschäftsprozesse kann ein Use Case deshalb mehr Kontext tragen.
Beide Artefakte können kombiniert werden. Eine User Story kann beispielsweise einen priorisierbaren Produktbedarf beschreiben, während ein Use Case den komplexen Ablauf dahinter dokumentiert.
Typische Fehler
- Technische Tasks werden künstlich als Nutzerstory formuliert.
- Das „damit“ enthält keinen echten Nutzen.
- Story ist so groß, dass mehrere unabhängige Ziele enthalten sind.
- Akzeptanzkriterien fehlen.
- Der Nutzer wird erfunden, ohne reale Stakeholder einzubeziehen.
- Tickets ersetzen Gespräche vollständig.
Praxisbeispiel: schlechte und bessere Story
Schwach: „Als Nutzer möchte ich ein Dashboard, damit ich ein Dashboard habe.“ Der Nutzen bleibt unklar.
Besser: „Als Vertriebsleiter möchte ich offene Angebote nach Fälligkeit und Verantwortlichem sehen, damit ich überfällige Vorgänge früh erkennen kann.“ Damit wird klarer, welche Entscheidung die Funktion unterstützt.
Wann ist eine User Story zu groß?
Wenn eine Story mehrere unabhängige Nutzerziele, viele Prozessphasen oder zahlreiche alternative Pfade enthält, ist sie häufig eher ein Epic oder ein Themencontainer. Die Aufteilung sollte jedoch entlang fachlichen Nutzens erfolgen und nicht in reine technische Schichten wie „Datenbank“, „Backend“ und „Frontend“, wenn dadurch kein prüfbarer Nutzerwert mehr entsteht.
Gute Zerlegung ermöglicht frühes Feedback: Jede kleinere Story sollte möglichst einen sinnvollen vertikalen Ausschnitt durch das System liefern.
Fazit
User Stories sind ein leichtgewichtiges Werkzeug für agile Anforderungen. Ihre Stärke liegt nicht in einem Satztemplate, sondern darin, fachlichen Nutzen sichtbar zu machen und gezielte Gespräche auszulösen. Für komplexe oder regulierte Anforderungen müssen sie durch geeignete weitere Artefakte ergänzt werden.
Passende Leistungen von Wils Solutions
Häufige Fragen
Wie ist eine User Story aufgebaut?
Ein verbreitetes Format lautet: Als [Rolle] möchte ich [Ziel], damit [Nutzen]. Das Format ist eine Heuristik und ersetzt nicht das Gespräch über Details.
Braucht jede User Story Akzeptanzkriterien?
In der Praxis sind klare Akzeptanzkriterien sehr hilfreich, um erwartetes Verhalten überprüfbar zu machen.
Was ist der Unterschied zwischen User Story und Use Case?
User Stories sind meist kurz und gesprächsorientiert. Use Cases beschreiben häufig ausführlicher Interaktionen, Hauptablauf und Alternativen.