Aus der agilen Methodenkiste: Die User Story

Vor geraumer Zeit erzählte mir jemand eine Geschichte, die sehr gut als Einstieg zum Thema „User Story“ passt.

In einer sehr großen Organisation erhielt die EDV-Abteilung den Auftrag, für den Vorstand eine automatisierte Abfrage aus dem Finanzwesen zu erstellen, und zwar mit der Anforderung, eine entsprechende Schnittstelle zu schaffen. Dort machte mensch sich sofort an die Arbeit und schätzte den Aufwand. Die Schätzung lag deutlich im mehrstelligen Stundenbereich. Entsprechend wurde an den Vorstand zurückgespiegelt, dass hierfür Finanzmittel im fünfstelligen Bereich benötigt werden. Die entsprechenden Mittel wurden genehmigt und mit der Umsetzung begonnen.

Erst im Nachgang erfahren die verantwortlichen Umsetzenden in der EDV-Abteilung, dass dieser Bericht nur einmal im Jahr benötigt wird. Der Bericht wäre mit einem händischen Arbeitsablauf in einer guten Stunde ebenfalls generierbar gewesen.

Was also ist hier passiert? Ganz einfach, die EDV-Leute haben das getan, was von ihnen erwartet wurde. Sie haben eine vorgegebene Lösung umgesetzt. Hätte mensch ihnen allerdings gesagt: „Wir brauchen für unser Berichtswesen eine Auswertung bestimmter Daten, und zwar einmal im Jahr“, hätten diese sicherlich verschiedene Optionen erarbeitet und geprüft. Und sie hätten vermutlich statt der Schnittstelle einen anderen Weg vorgeschlagen, der aus wirtschaftlicher Sicht sinnvoller gewesen wäre.

Mit der Maßgabe eine Schnittstelle zu programmieren, war der Weg aber bereits vorgegeben. Damit so etwas nicht passiert, setzen viele Agilisten auf die sogenannte User Story. Wie der Namensbestandteil „User (= Anwender)“ schon andeutet, auch ein Begriff, der im Umfeld der Softwareentwicklung entstanden ist. Das Konzept lässt sich aber auf alle möglichen Situationen, bei denen „Kunden“ einem Dienstleister den Auftrag zur Entwicklung eines „Produkts“ erteilen, mit großem Nutzen anwenden. (Also z. B. auch in der Organisationsentwicklung.)

User Story – was ist das?

Eine User Story weist in aller Regel folgenden Grundstruktur auf: Als < Rolle > will ich < Handlung >, um < Ergebnis > zu erzielen. Im oben genannten Beispiel wäre dann die User Story gewesen: „Als Vorstand möchte ich einmal im Jahr folgende Daten zur Erstellung eines Berichts zur Verfügung gestellt haben.“

Eine User Story könnte mensch daher als Beschreibung einer Anforderung bezeichnen, die ein Ergebnis definiert und die begründet, warum dieses Ergebnis benötigt wird. Diese Anforderung lässt vollständig offen, wie das Ergebnis erzielt wird. Damit werden keine Lösungen vorgegeben oder determiniert. Sondern im Gegenteil, das „Wie“ bleibt offen, und wer auch immer an die Umsetzung geht, muss sich nicht an eine vorgegebene Lösung halten, die sich möglicherweise als unwirtschaftlich herausstellt.

Die Vorteile

User Storys haben den Vorteil, dass sie leicht für alle Beteiligten zu verstehen sind und einer einfachen Struktur folgen, die dennoch hochgradig effektiv und effizient ist. Sie lassen sich unterschiedlich ausführlich dokumentieren und ganz einfach mit fortschreitendem Projekt verfeinern und anpassen. Sie sind damit ideal, gerade für agile Methoden, bei denen im Laufe der Zeit von grobkörnigen Anforderungen zu feinkörnigen Beschreibungen übergegangen wird. Sprich im Zuge der Fortschreibung des Backlogs (dem Themenspeicher mit den priorisierten Anforderungen) werden die am höchsten priorisierten Anforderungen umso detaillierter beschrieben, je höher sie bewertet werden. Anforderungen detailliert zu beschreiben, die in der Priorität weit unten liegen und auch in den nächsten zwei bis drei Sprints nicht relevant werden, macht wenig Sinn. Denn bis diese zum Zuge kommen könnten, liegen neue Erkenntnisse vor, die zu einer vollkommen neuen Bewertung führen.

Die Entwicklung einer User Story ist daher ein dauerhafter Dialog zwischen den Beteiligten. Der Fokus verschiebt sich damit weg vom Schreiben hin zum Dialog im Sinne des Informationsaustausches und der Zusammenarbeit. Ziel ist es, ein besseres Verständnis davon zu entwickeln, was erreicht werden soll. Wesentlicher Teil einer jeden User Story sind die Akzeptanzkriterien. Diese beschreiben, welche Kriterien erfüllt sein müssen, damit der Auftraggeber mit dem Ergebnis zufrieden ist und verhelfen dem Team damit zu einem besseren Verständnis darüber, was gewünscht ist.

Arten von User Stories

User Storys werden häufig unterschieden in sprintfähige Storys, die sich innerhalb einer Planungsphase (Sprint) realisieren lassen. Darüber hinaus werden zusammenhängende Storys (die z. B. funktional zusammengehören) häufig als „Theme“ zusammengefasst. User Storys mit einer Größe, die über mehrere Planungsphasen hinaus reichen, tragen häufig die Bezeichnung Epics. Diese Bezeichnungen sind nicht in Stein gemeißelt und können durchaus abweichen, haben aber einen hohen Verbreitungsgrad und werden in der einschlägigen Literatur in aller Regel verwendet.

Von den User Storys abzugrenzen sind die Aufgaben. Damit werden Tätigkeiten bezeichnet, die sich in wenigen Stunden erledigen lassen. Also die klassischen „Aufgaben“ der Aufgabenliste, wie wir sie alle kennen.

Formulierungshilfe

Von Bill Wake stammen sechs Kriterien für die Formulierung von User Storys, die unter dem Akronym INVEST Verbreitung gefunden haben und sich in der Praxis bewährt haben.

Unabhängig in diesem Sinne bedeutet, dass zwischen den User Storys selbst entweder keine oder nur lose Abhängigkeiten bestehen. So, dass jede Story für sich betrachtet und erarbeitet werden kann, ohne Risiken durch zusätzliche komplexe Zusammenhänge berücksichtigen zu müssen.

Verhandelbar bedeutet, dass die User Story weiterhin im Dialog weiterentwickelt werden soll. Der Dialog soll nicht behindert werden, sodass Spielräume entstehen, die die Anpassungsfähigkeit an neue Erkenntnisse ermöglichen. Werthaltig bedeutet, dass eine User Story für den „Auftraggeber“ einen Nutzen stiften soll. Der Nutzen ist neben dem Aufwand eines der zentralen Kriterien bei der Bewertung der Priorität. Je höher der Nutzen und damit der Wert und je geringer der Aufwand, desto höher die Priorität innerhalb des priorisierten Themenspeichers (Backlog).

Schätzbar bedeutet, dass der Aufwand zur Umsetzung realistisch einschätzbar sein muss. Ist dies nicht der Fall, ist die User Story möglicherweise zu groß und muss in mehrere kleinere Einheiten zerlegt werden. Wie bereits erwähnt, ist der Aufwand – neben dem Wert – einer der zentralen Faktoren zu Priorisierung. Daneben sollten Storys immer die passende Größe aufweisen. D. h. sie müssen von der Größe dem Planungs- und Umsetzungszyklus entsprechen. Zu guter Letzt ist eine gute User Story prüfbar, sprich es kann mithilfe der definierten Akzeptanzkriterien gegengespiegelt werden, ob die tatsächlich auch alle Kriterien erfüllt sind, wenn die User Story umgesetzt wurde.

Fazit

Autor: Thomas Michl

Agilist aus Überzeugung - Lean-Enthusiast und Kanban-Fan - Veränderungsbegleiter - Dipl.-Verw.Wiss. - MBA - 🇮🇪 Irland-Fan - Mitgründer Forum Agile Verwaltung Zeige alle Beiträge von Thomas Michl