User Story
Eine kurze Beschreibung einer Funktionsanforderung aus Sicht eines Anwenders im Format „Als ... moechte ich ... damit ...".
Eine User Story ist ein kurzes, formularhaftes Beschreibungsformat für Anforderungen aus agiler Software-Entwicklung. Sie folgt dem Muster „Als <Rolle> moechte ich <Funktion>, damit <Nutzen>". Ziel ist es, Anforderungen aus der Perspektive eines konkreten Anwenders mit seiner Motivation zu erfassen – nicht als technische Spezifikation, sondern als Diskussionsgrundlage.
Ausführliche Erklärung
Das Format einer User Story hat drei Bestandteile: die Rolle (z. B. „Als Admin", „Als Trial-Nutzer"), der gewünschte Funktionsbaustein („moechte ich Vorschläge per CSV exportieren") und der dahinterliegende Nutzen („damit ich sie offline analysieren kann"). Der Nutzenteil ist oft der wichtigste – er gibt dem Entwicklungsteam den Kontext, um Alternativen zu erkennen, wenn die woertliche Lösung schwierig wäre.
User Stories werden meist auf Karten oder in Ticket-Systemen geführt und sind bewusst kurz. Sie ersetzen keine vollständige Spezifikation – diese entsteht in der gemeinsamen Diskussion zwischen Produkt, Design und Entwicklung. Eine Story ist eher ein „Versprechen einer Konversation" als ein fertiges Lastenheft.
Damit eine Story bearbeitbar ist, werden meist Akzeptanzkriterien ergänzt – konkrete, testbare Aussagen darüber, wann die Story als „fertig" gilt. Zum Beispiel: „CSV-Datei enthaelt alle Vorschläge mit Titel, Status und Vote-Anzahl. Header-Zeile vorhanden. Sortierung nach Erstelldatum aufsteigend." Akzeptanzkriterien sind oft auch die Grundlage für automatisierte Tests.
Die INVEST-Heuristik beschreibt sechs Eigenschaften, die eine gute User Story haben sollte: Independent (unabhängig von anderen Stories umsetzbar), Negotiable (verhandelbar – kein fixes Lastenheft), Valuable (liefert klaren Nutzen), Estimable (schätzbar im Aufwand), Small (klein genug für einen Sprint) und Testable (mit klaren Akzeptanzkriterien). Wenn eine Story diese Eigenschaften nicht erfüllt, ist das oft ein Hinweis, sie weiter zu zerlegen.
In der Praxis werden User Stories häufig aus Feature Requests im Feedback Board abgeleitet. Ein Vorschlag eines Endkunden („Bitte CSV-Export") wird im Produktteam zu einer oder mehreren Stories ausformuliert, mit Akzeptanzkriterien versehen und priorisiert. Die Story behaelt dabei die Verbindung zum ursprünglichen Voter, sodass die Person bei Statuswechsel automatisch informiert werden kann.
Praxisbeispiel
Ein Produktteam formuliert aus dem Feedback Board den Vorschlag „CSV-Export für Vorschläge" als Story: „Als Board-Admin moechte ich alle Vorschläge als CSV exportieren, damit ich eine quartalsweise Reporting-Analyse in Excel durchführen kann." Akzeptanzkriterien: Spalten Titel, Status, Votes, Kategorie; UTF-8 mit BOM; Trennzeichen Semikolon. Aus der Story entsteht im Sprint ein Ticket und am Ende ein neuer Menupunkt im Admin-Panel.
Vorteile
- Stellt die Nutzerperspektive in den Vordergrund statt der technischen Implementierung.
- Ist klein genug, um in einem Sprint umgesetzt zu werden – im Gegensatz zu seitenlangen Anforderungsdokumenten.
- Fördert Konversationen statt Vertragsverhandlungen, weil Details bewusst offen bleiben.
- Verbindet Anforderung mit Nutzen, was bei späteren Priorisierungs-Diskussionen hilft.
Haeufige Fehler und Missverstaendnisse
- Stories ohne Akzeptanzkriterien aufschreiben – Entwicklungsteam und Produktmanagement haben dann unterschiedliche Vorstellungen vom „Fertig"-Zustand.
- Den Nutzenteil pauschal formulieren („damit es besser ist") – ohne konkreten Nutzen ist die Story nicht priorisierbar.
- Stories als reine Backlog-Verwaltung verwenden statt als Diskussions-Anstoss – wenn niemand über die Story spricht, ist sie nur ein anderes Format für ein klassisches Lastenheft.
Verwandte Begriffe
Feature Requests mit ideenkiste.app sammeln – kostenlos starten
Strukturiertes Feedback-Board, Voting, oeffentliche Roadmap und Magic-Link-Login. In zwei Minuten startklar.
Kostenlos startenZuletzt aktualisiert: