User Story
Eine kurze, nutzerzentrierte Beschreibung einer Anforderung zur Kommunikation und Planung von Wert in agilen Teams.
Klassifikation
- KomplexitätMittel
- AuswirkungGeschäftlich
- EntscheidungstypDesign
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlende Definition führt zu falschen Implementierungen.
- Stakeholder-Expectation-Mismatch bei unklaren Stories.
- Technische Schulden durch vernachlässigte Nichtfunktionales.
- Formuliere Stories klein genug für einen Sprint.
- Nutze klare, überprüfbare Akzeptanzkriterien.
- Diskutiere Stories im Team statt sie allein zu schreiben.
I/O & Ressourcen
- Stakeholder-Anforderungen oder Nutzerfeedback
- Produktvision oder Epic-Beschreibungen
- Vorhandene technische Randbedingungen
- Kleine, priorisierte und testbare User Stories
- Akzeptanzkriterien und Annahmen
- Klärungsbedarf und definierte Nachaufgaben
Beschreibung
Die User Story ist eine kurze, nutzerzentrierte Beschreibung einer Anforderung, die funktionales Verhalten in Alltagssprache festhält. Sie dient Teams zur Priorisierung, Planung und Kommunikation von Wertversprechen. User Stories fördern inkrementelle Lieferung, Diskussion und frühe Validierung von Annahmen im agilen Kontext.
✔Vorteile
- Verbessert Kommunikation zwischen Fach und Entwicklung.
- Ermöglicht priorisierte, inkrementelle Lieferung von Wert.
- Fördert frühe Validierung von Annahmen.
✖Limitationen
- Kann unpräzise sein ohne klare Akzeptanzkriterien.
- Nicht geeignet als vollständiger Spezifikationsersatz für komplexe Integrationen.
- Übermäßige Fragmentierung kann Kontextverlust verursachen.
Trade-offs
Metriken
- Durchlaufzeit pro Story
Zeit vom Erstellen bis zum Abschluss einer User Story.
- Anzahl abgeschlossener Stories pro Sprint
Messung des Liefervolumens pro Iteration.
- Fehlerquote nach Lieferung
Anzahl der Defekte, die nach Implementierung entdeckt wurden.
Beispiele & Implementierungen
Login per E-Mail (Beispiel)
Eine Story beschreibt den Login aus Sicht eines Nutzers inklusive Akzeptanzkriterien.
Onboarding-Flow (Beispiel)
Schrittweise Stories, die den ersten Nutzungserfolg gewährleisten.
Premium-Feature Freischalten (Beispiel)
Story mit Akzeptanzkriterien für Berechtigungen und Abrechnungsschnittstelle.
Implementierungsschritte
Einführung einer konsistenten Story-Struktur (Persona, Ziel, Nutzen).
Schulung des Teams zu INVEST-Prinzipien und Akzeptanzkriterien.
Regelmäßige Refinement-Sessions etablieren.
Metriken definieren und kontinuierlich überwachen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Wiederkehrende technische Schulden durch vernachlässigte Architektur.
- Kurzfristige Workarounds, die später aufgearbeitet werden müssen.
- Unvollständige Akzeptanzkriterien führen zu Nacharbeit.
Bekannte Engpässe
Beispiele für Missbrauch
- Verwendung von Stories als detaillierte technische Spezifikation.
- Erstellen vieler kleiner Stories ohne übergeordneten Kontext.
- Ignorieren von nicht-funktionalen Anforderungen.
Typische Fallen
- Zu grobe Formulierungen führen zu Interpretationsspielraum.
- Zu starke Fokussierung auf Schätzung statt Wert.
- Story-Splitting ohne Rücksicht auf Benutzerfluss.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Zeitbegrenzte Refinement-Kapazität
- • Abhängigkeit von Stakeholder-Verfügbarkeit
- • Nichtfunktionale Anforderungen separat beachten