Wir entwickeln immer mit dem Nutzer – nicht der Technik – im Fokus. Denn, ist die Technik auch noch so gut, entwickelt man am Nutzer-Nutzen vorbei ist das Ergebnis trotzdem schlecht. Daher hat es natürlich auch Sinn in der Entwicklung die Nutzer Perspektive zu instrumentalisieren. Wir machen das mithilfe von User Stories, einem der Kernelemente agiler Entwicklung.
Was ist eine User Story?
Wie der Name vermuten lässt, ist eine User Story aus der Sicht des Anwenders und in Form einer kurzen Geschichte geschrieben. Meist wird dafür ein klassisches Satzschema verwendet:
"Als { Akteur } möchte ich { Funktion }, damit { Nutzen }."
Mit einem Beispiel wird aus dem kryptischen Satz dann auch etwas Sinnvolles:
Als { Kunde von XY } möchte ich { schnell und transparent an ein verlässliches Angebot kommen }, damit ich { Preise vergleichen und eine Kaufentscheidung treffen kann }.
Eigenschaften einer User Story
Eine User Story sollte gewisse Eigenschaften aufweisen um möglichst effektiv bearbeitet werden zu können:
Passt auf eine Karte
Die ganze Story soll auf eine kleine Karte passen. Die simple Idee dahinter ist, dass wenn eine Story nicht auf eine Karte passt, sie einfach zu umfangreich ist. In diesem Fall sollte sie in mehrere Stories heruntergebrochen werden. Längere, vollständigere Beschreibungen, können außerdem in den mehr holistischen User Journey Platz finden.
Hat einen prägnanten Name
Neben der eigentlichen Geschichte sollte eine User Story noch einen prägnanten kurzen und deskriptiven Namen bekommen. In unserem Beispiel vielleicht:
Erstellung von einem Kunden-Angebot
Hat Akzeptanzkriterien
Zu guter Letzt sollte eine User Story noch mit Akzeptanzkriterien versehen werden. Diese helfen dabei festzustellen, ob die gewünschte Funktion wirklich richtig implementiert wurde. Eine gute Möglichkeit diese Kriterien herauszuarbeiten ist zu fragen: Woran erkennen wir, dass wir die User Story gelöst haben?
Für unser Beispiel:
- Ein Kunde kann sich ein individuelles Angebot auf unserer Webseite mit wenigen Klicks zusammenstellen.
- Das Angebot ist verlässlich und korrekt.
- Kunde und Angebot werden auch in unserem CRM angelegt.
- Die Angebotserstellung funktioniert für alle unsere Produktkategorien
Epics und die Verfeinerung von User Stories
Oftmals sind auch User Stories noch sehr weit gefasst, da sie zunächst auf einem eher groben Niveau festgehalten werden. In unserem Beispiel hat sich zum Beispiel durch die Akzeptanzkriterien eine erhöhte Komplexität offenbart, die aus der Story selbst noch nicht ersichtlich war.
Das Schöne am System der User Stories ist, dass es eine einfache Methodik gibt mit diesem (häufigen) Phänomen umzugehen: Die User Story wird zu einem Epic – einer übergeordneten User-Story mit mehreren "Kinder Stories".
Diese müssen allerdings nur dann durchdacht und erstellt werden, wenn der Epic tatsächlich umgesetzt wird. Das spart Zeit und Ressourcen in der Planung, wenn evtl. noch gar nicht sicher ist, ob dieses Feature überhaupt gebraucht wird.
In unserem Beispiel könnte der Epic in folgende Unter-Stories aufgeteilt werden:
- Erstellung eines Angebotsgenerators
- Anlegen des Angebots in unserem CRM
- Aufbereitung der Produktdaten für eine Angebotskalkulation
User Stories in Production
Eine der einfachsten Varianten – und unsere präferierte – wie User Stories in der Produktion Anwendung finden ist auf einem Kanban Board (sowas wie Trello). In seiner klarsten Variante besteht dieses aus den drei Säulen: To Do, Doing und Done. Die User Stories sind dann quasi "To-Do-Items" in den einzelnen Säulen und können zwischen diesen verschoben werden.
Oftmals wird das Kanban Board noch um eine vierte Säule ergänzt, um übersichtlich zu bleiben: den Backlog. Hier werden User Stories "aufbewahrt" die erst zu einem späteren Zeitpunkt oder Sprint umgesetzt werden sollen.
