Stellen Sie sich vor, Sie wollen mit ihrem Smartphone ein Taxi bestellen. Sie stehen an einer Kreuzung, nutzen die praktische App und diese zeigt Ihnen an, wie viele Taxis in Ihrer Nähe zur Verfügung stehen. Leider wird „Nähe“ hier anders definiert, als Sie vielleicht gedacht haben. Denn es werden alle Taxis im Umkreis von 20 km angezeigt. Jetzt können Sie munter drauflos scrollen, um das passende Taxi zu buchen. Sie fragen sich „Wer zum Henker hat diese App programmiert?“ und rufen doch lieber den Taxifunk an. Damit es gar nicht erst soweit kommt, nutzen agile Entwicklungsteams User Stories.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Der Nutzen im Vordergrund
User Stories sind kurze, einfache Beschreibungen eines Features (Produktfunktion) aus der Perspektive der Person, die sich die neue Funktion wünscht. Das ist in der Regel ein Nutzer bzw. Kunde. Sie werden prinzipiell von allen an der Produktentwicklung beteiligten Personen geschrieben und werden meist auf Karteikarten oder Haftnotizen festgehalten, in einem Schuhkarton aufbewahrt oder zur Erleichterung der Planung und Diskussion an Wänden oder Tischen angeordnet. Sie folgen typischerweise dieser einfachen Vorlage:
Als < Benutzerrolle > möchte ich < ein Ziel >, so dass < ein Grund für das Ziel >.
Der Sinn von User Stories ist, eine Diskussion über Realisierungaufwand und Prioritäten zu befeuern. Die Betonung sollte daher immer auf dem wichtigen dritten Teil im Muster der User Story liegen, also dem Nutzen der Funktion. Es lohnt sich häufig, die User Story umzudrehen und den Nutzen voranzustellen:
Um < ein Grund für das Ziel > möchte ich als < Benutzerrolle > < ein Ziel >.
Ein Vorteil agiler User Stories ist, dass sie in unterschiedlichen Detaillierungsgraden geschrieben werden können. Wir können eine User Story schreiben, um große Mengen an Funktionalität abzudecken. Diese großen User Stories sind allgemein als Epics bekannt. Hier ein Beispiel:
Als Benutzer möchte ich mit meinem Smartphone den nächst verfügbaren Taxifahrer buchen, um schnell ans Ziel zu kommen.
Wie werden User Stories konkreter?
- Durch die Aufteilung einer User Story in mehrere, kleinere User Stories.
- Durch das Hinzufügen von „Akzeptanzkriterien“
Da ein Epic in der Regel zu groß ist, als dass ein agiles Team es in einer Iteration abschließen könnte, wird es vor der Bearbeitung in mehrere kleinere User Stories aufgeteilt. Das obige Epos könnte in Dutzende (oder möglicherweise Hunderte) aufgeteilt werden, einschließlich dieser beiden:
Als Taxifahrer möchte ich meine Verfügbarkeit an- und ausschalten können, um meine Arbeitszeiten und Pausen einteilen zu können.
Als Taxigast möchte ich meinen Standort teilen können, damit mir das nächst verfügbare Taxi angezeigt wird.
Darüber hinaus sollten vor einer Iteration (i.d.R. vom Product Owner) sogenannte Akzeptanzkriterien festgelegt werden, die am Ende eines Entwicklungszyklus überprüft werden. In unserem Taxifahrer-Beispiel könnten diese folgendermaßen lauten:
Stelle sicher, dass Benutzer dem „Standort teilen“ zustimmen.
Stelle sicher, dass der Benutzer-Standort nur mit Taxifahrern geteilt wird, die sich in einem Radius von 5 Kilometer aufhalten.
Auf einen Blick
- User Stories dienen neben Epics als Kommunikationsbrücke zwischen Kunden, Technikern, Designern und Lieferanten. Für das Team stellen sie eine Diskussionsgrundlage für das weitere Vorgehen dar.
- User Stories bestehen aus wenigen Sätzen, sind kurz, knapp und verständlich, aus Kundensicht jedoch spezifisch und detailliert.
- Eine User Story beantwortet drei Fragen:
1. Wer fordert etwas an? (Rolle)
2. Was wünscht sich der Anforderer? (Funktion)
3. Warum ist das für den Geschäftsfall wichtig? (Nutzen)
