Viele Teams benutzen mittlerweile User Stories. Was ist euer Rezept wie man gute User Stories schreibt?
1 Antwort
Zu allererst fällt mir dazu ein: Gute User Stories haben nichts damit zu tun, wie besonders fein sie ausdetailliert sind. Was im Wasserfallvorgehen noch ein Vorteil war (Detailspezifikation), steht bei agilem Vorgehen im Wege bzw. fördert die (unbewusste) Missachtung agiler Prinzipien, z.B. User Stories gemeinsam mit dem Entwicklungsteam zu erarbeiten.
Die Kernintention von User Stories ist: Eine User Story ist ein Versprechen auf eine spätere Diskussion. Daher auch der Begriff 'Story', also eine Geschichte, die von einem zu lösenden Problem des Anwenders handelt.
Im Kern besteht deshalb eine User Story aus der eigentlichen User Story im Format: Als ANWENDER möchte ich FUNKTIONALITÄT, damit PROBLEM gelöst wird. Diese Bedingungen, die eine dazu passende technische Lösung erfüllen muss, werden als Akzeptanzkriterien (wiederum gemeinsam mit dem Entwicklungsteam) erarbeitet und erfasst. Z.B. in Form von GEGEBEN Vorbedingung, WENN Aktion, DANN Resultat.
Weiterhin hat sich das INVEST Prinzip bewährt. Dies bedeutet eine User Story ist dann gut, wenn sie:
I(ndependent), also unabhängig von anderen User Stories ist bzw. in sich abgeschlossen (nicht immer einfach!)
N(egotiable), also verhandelbar bzgl. ihrer Lösung ist (z.B. keine vorgegebene Implementierungslösung vorschreibt)
V(aluable), also von Nutzen für den Endanwender ist (zwei halbe 5-Euroschein sind 0 Euro wert!)
E(stimatable), also schätzbar bzgl. ihres Wertes, wie auch ihres Lösungsaufwandes ist
S(mall), also klein ist, um die Komplexität (Unwägbarkeiten) im Griff zu haben, oft mindestens so klein, dass sie innerhalb eines Sprints umgesetzt werden kann.
T(estable), also über Akzeptanzkritierien prüfbar ist, ob das Problem (das die Funktionalität löst) richtig gelöst wurde.
Am allerwichtigsten ist aber, dass nicht das SCHREIBEN im Vordergrund steht, sondern die DISKUSSION. Ein sehr gängiger Fehler ist, dass User Stories mit klassischen Anforderdungen verwechselt werden. Vom Prinzip her aber unterscheiden sich beide grundlegend in ihrer Herangehensweise. Z.B. in der klassischen Anforderungswelt werden ausdetaillierte Anforderungen 'übergeben' (über den Zaun werfen). Das dabei immanent vorhandene Risiko des Informationsverlustes (Geschriebenes ist nicht Gelesenes, Gelesenes ist nicht Verstandenes etc.) kommt in der Praxis praktisch immer vor, ist zu aufwändig und hat sich nicht bewährt. Dagegen werden User Stories oft unter Anwendung geeigneter Visualisierungstechniken (z.B. Story Mapping) gemeinsam erarbeitet, um vor allem das gemeinsame Verständnis sicher zu stellen. Dies ist eine fundamental andere Herangehensweise. Wer also jemals das Gefühl hatte, User Stories seien nur alter Wein in neuen Schläuchen, darf sich sicher sein, dass er einem grundlegendem Denkfehler unterliegt.
Die Kernintention von User Stories ist: Eine User Story ist ein Versprechen auf eine spätere Diskussion. Daher auch der Begriff 'Story', also eine Geschichte, die von einem zu lösenden Problem des Anwenders handelt.
Im Kern besteht deshalb eine User Story aus der eigentlichen User Story im Format: Als ANWENDER möchte ich FUNKTIONALITÄT, damit PROBLEM gelöst wird. Diese Bedingungen, die eine dazu passende technische Lösung erfüllen muss, werden als Akzeptanzkriterien (wiederum gemeinsam mit dem Entwicklungsteam) erarbeitet und erfasst. Z.B. in Form von GEGEBEN Vorbedingung, WENN Aktion, DANN Resultat.
Weiterhin hat sich das INVEST Prinzip bewährt. Dies bedeutet eine User Story ist dann gut, wenn sie:
I(ndependent), also unabhängig von anderen User Stories ist bzw. in sich abgeschlossen (nicht immer einfach!)
N(egotiable), also verhandelbar bzgl. ihrer Lösung ist (z.B. keine vorgegebene Implementierungslösung vorschreibt)
V(aluable), also von Nutzen für den Endanwender ist (zwei halbe 5-Euroschein sind 0 Euro wert!)
E(stimatable), also schätzbar bzgl. ihres Wertes, wie auch ihres Lösungsaufwandes ist
S(mall), also klein ist, um die Komplexität (Unwägbarkeiten) im Griff zu haben, oft mindestens so klein, dass sie innerhalb eines Sprints umgesetzt werden kann.
T(estable), also über Akzeptanzkritierien prüfbar ist, ob das Problem (das die Funktionalität löst) richtig gelöst wurde.
Am allerwichtigsten ist aber, dass nicht das SCHREIBEN im Vordergrund steht, sondern die DISKUSSION. Ein sehr gängiger Fehler ist, dass User Stories mit klassischen Anforderdungen verwechselt werden. Vom Prinzip her aber unterscheiden sich beide grundlegend in ihrer Herangehensweise. Z.B. in der klassischen Anforderungswelt werden ausdetaillierte Anforderungen 'übergeben' (über den Zaun werfen). Das dabei immanent vorhandene Risiko des Informationsverlustes (Geschriebenes ist nicht Gelesenes, Gelesenes ist nicht Verstandenes etc.) kommt in der Praxis praktisch immer vor, ist zu aufwändig und hat sich nicht bewährt. Dagegen werden User Stories oft unter Anwendung geeigneter Visualisierungstechniken (z.B. Story Mapping) gemeinsam erarbeitet, um vor allem das gemeinsame Verständnis sicher zu stellen. Dies ist eine fundamental andere Herangehensweise. Wer also jemals das Gefühl hatte, User Stories seien nur alter Wein in neuen Schläuchen, darf sich sicher sein, dass er einem grundlegendem Denkfehler unterliegt.