User Story

Eine User Story ist ein zentrales Element in agilen Methoden, das eine Funktionalität aus der Perspektive eines Benutzers beschreibt. User Stories sind bewusst kompakt gehalten und fokussieren sich darauf, WER etwas tun möchte, WAS getan werden soll und WARUM es wertvoll ist. Sie dienen als Grundlage für Diskussionen zwischen Entwicklungsteam, Product Owner und Stakeholdern.

Aufbau und Format einer User Story

Die klassische Struktur einer User Story folgt dem Format:

Als <Rolle/Benutzertyp> möchte ich <Ziel/Wunsch>, damit <Nutzen/Mehrwert>.

Beispiele:

• "Als Online-Shopper möchte ich Produkte nach Preis filtern können, damit ich Artikel finde, die in mein Budget passen."
• "Als Projektmanager möchte ich den Fortschritt aller Aufgaben in einer Übersicht sehen, damit ich gefährdete Deadlines frühzeitig erkennen kann."
• "Als mobiler Nutzer möchte ich die Website mit einer Hand bedienen können, damit ich auch unterwegs problemlos navigieren kann."

Eigenschaften guter User Stories

Das INVEST-Prinzip beschreibt die Eigenschaften hochwertiger User Stories:

• Independent (Unabhängig): Eine Story sollte eigenständig umsetzbar sein ohne starke Abhängigkeiten zu anderen Stories.
• Negotiable (Verhandelbar): Die Details der Umsetzung sind nicht fest vorgegeben, sondern werden im Team erarbeitet.
• Valuable (Wertvoll): Eine Story muss einen erkennbaren Wert für Benutzer oder Kunden liefern.
• Estimable (Schätzbar): Das Team muss den Aufwand für die Umsetzung hinreichend einschätzen können.
• Small (Klein): Stories sollten klein genug sein, um innerhalb eines Sprints umgesetzt werden zu können.
• Testable (Testbar): Es muss klare Kriterien geben, anhand derer die Fertigstellung verifiziert werden kann.

User Stories vs. Anforderungsspezifikationen

User Stories unterscheiden sich fundamental von traditionellen Anforderungsspezifikationen:

User Stories	Anforderungsspezifikationen
Kurz und prägnant	Umfangreich und detailliert
Benutzerorientiert	Oft technisch orientiert
Betonen den Nutzen ("Warum")	Fokus auf Funktionalität ("Was")
Startpunkt für Gespräche	Abschließendes Vertragsdokument
Entstehen und entwickeln sich iterativ	Werden im Voraus umfassend definiert
Flexibilität in der Umsetzung	Strikte Vorgaben zur Implementierung

Die 3 C's der User Stories

User Stories werden oft nach dem "3C"-Prinzip beschrieben:

1. Card: Die physische oder digitale Karte, auf der die Story in wenigen Sätzen notiert ist. Sie dient als Erinnerung für eine Konversation.
2. Conversation: Der Dialog zwischen Stakeholdern, Product Owner und Entwicklungsteam, in dem die Details der Story erarbeitet werden.
3. Confirmation: Die Akzeptanzkriterien, die definieren, wann eine Story als "fertig" gilt.

Akzeptanzkriterien

Akzeptanzkriterien sind ein wesentlicher Bestandteil von User Stories. Sie definieren konkret, welche Bedingungen erfüllt sein müssen, damit eine Story als erfolgreich umgesetzt gilt.

Beispiel für Akzeptanzkriterien zur Story "Als Online-Shopper möchte ich Produkte nach Preis filtern können":

• Benutzer können einen Minimal- und Maximalpreis angeben
• Die Preisfilterung wird in Echtzeit angewendet, ohne Neuladen der Seite
• Ein Preisschieberegler ist verfügbar und funktioniert auch auf Mobilgeräten
• Nach Anwendung des Preisfilters werden nur Produkte innerhalb des Preisbereichs angezeigt
• Der aktuell angewendete Preisfilter wird dem Benutzer deutlich angezeigt

Häufig werden Akzeptanzkriterien im "Given-When-Then"-Format formuliert:

• "Given ich befinde mich auf der Produktübersichtsseite, when ich den Preisfilter auf 50-100 € einstelle, then werden nur Produkte in diesem Preisbereich angezeigt."

User Story Mapping

User Story Mapping ist eine Technik, um User Stories in einen größeren Kontext einzuordnen und zu organisieren:

• Stories werden horizontal nach Benutzeraktivitäten gruppiert (der "Backbone")
• Vertikal werden Stories nach Priorität oder Entwicklungsreihenfolge angeordnet
• Ermöglicht das Visualisieren der Benutzerreise und des Produktumfangs
• Hilft, Lücken im Funktionsumfang zu identifizieren
• Unterstützt die Release-Planung durch visuelle Priorisierung

Größe und Granularität von User Stories

User Stories existieren in verschiedenen Größenordnungen:

• Epics: Große, umfassende Stories, die zu groß für einen Sprint sind und in kleinere Stories aufgeteilt werden müssen.
• Features: Mittelgroße Stories, die mehrere zusammenhängende Funktionalitäten umfassen können.
• User Stories: Die Standardgröße, idealerweise innerhalb eines Sprints umsetzbar.
• Tasks: Technische Aufgaben, die zur Umsetzung einer User Story erforderlich sind.

Das "Slicing" (Aufteilen) großer Stories in kleinere, umsetzbare Einheiten ist eine wichtige Fähigkeit in agilen Teams. Dabei sollten die resultierenden Stories weiterhin eigenständigen Wert bieten.

Priorisierung von User Stories

User Stories werden im Product Backlog priorisiert, wobei verschiedene Faktoren berücksichtigt werden:

• Geschäftswert: Wie wichtig ist die Funktionalität für das Geschäftsziel?
• Risiko: Enthält die Story technische oder geschäftliche Risiken?
• Abhängigkeiten: Ist die Story Voraussetzung für andere wichtige Funktionen?
• Aufwand/Nutzen-Verhältnis: Steht der Aufwand im angemessenen Verhältnis zum erwarteten Nutzen?
• Lernwert: Liefert die Umsetzung wichtige Erkenntnisse für das weitere Vorgehen?

Gängige Priorisierungstechniken sind:

• MoSCoW (Must have, Should have, Could have, Won't have)
• Kano-Modell (Basis-, Leistungs- und Begeisterungsfaktoren)
• Relative Wertpriorisierung
• Buy a Feature (Stakeholder "kaufen" Features mit begrenztem Budget)

User Stories in verschiedenen agilen Frameworks

User Stories werden in verschiedenen agilen Ansätzen unterschiedlich gehandhabt:

• Scrum: Stories sind die Haupteinheiten im Product Backlog und werden während Sprint Planning für den Sprint Backlog ausgewählt.
• Kanban: Stories fließen kontinuierlich durch den Workflow, ohne feste Sprint-Grenzen.
• XP (Extreme Programming): User Stories werden oft mit Acceptance Test-Driven Development (ATDD) verknüpft.
• SAFe: Stories werden hierarchisch in Epics, Features und Stories organisiert und sind auf Team-, Programm- und Portfolio-Ebene relevant.

Häufige Herausforderungen und Lösungsansätze

• Zu technische Stories: Fokus zurück auf Benutzerperspektive lenken, "Warum" herausarbeiten.
• Zu große Stories: Vertikale Slices bilden, die eigenständigen Wert liefern.
• Unklare Akzeptanzkriterien: Testfälle formulieren, Beispiele sammeln, Workshops durchführen.
• Fehlender Kontext: Stories im Rahmen von User Journeys oder Story Maps diskutieren.
• Überspezifikation: Auf Ergebnisse fokussieren, nicht auf detaillierte Lösungswege.

Tools und Templates

Zur Verwaltung von User Stories werden verschiedene Ansätze und Tools verwendet:

• Physische Boards: Haftnotizen auf Whiteboards oder Kanban-Boards
• Digitale Tools: Jira, Trello, Azure DevOps, GitHub Issues, Pivotal Tracker
• Templates: Vorlagen für Stories und Akzeptanzkriterien
• Workshopformate: Story-Writing-Workshops, Backlog Refinement, User Story Mapping

In der Praxis ist es weniger wichtig, sich strikt an ein bestimmtes Format zu halten, als vielmehr den Kern der User Story zu erfassen: den Benutzer, sein Ziel und den damit verbundenen Wert. User Stories sind ein Kommunikationswerkzeug, das Teams dabei hilft, sich auf die Bedürfnisse der Benutzer zu konzentrieren und gemeinsam wertvolle Software zu entwickeln.