Amon Engemann
Managing Consultant
Egal ob alter Hase oder Frischling – es wird von allen implizit erwartet, dass sie wissen, wie eine User Story geschrieben wird. Das kann doch auch gar nicht so schwer sein. Schließlich ist das nur eine Satzvorlage, in die einfach ein paar Begriffe eintragen werden müssen. Doch vor allem in großen Institutionen lässt sich beobachten, dass ohne Rücksicht und teils mit Gewalt eigene Interessen in das Template gepresst werden. Ein (leicht verfremdetes) Realbeispiel, das ihr gerne mehrmals lesen dürft: Als Vorgesetzter möchte ich zur Sicherstellung der Erreichung der Quartalsziele ein optimal aufgestelltes Team, damit die Mitarbeiter mit Sinn und Freude eine optimale Produktivität entfalten können.
Dabei sollte eine User Story weder von den Interessen des Vorgesetzten noch von denen der Mitarbeiter handeln. Das eigentliche Ziel bei der Erstellung einer User Story ist es, Empathie für unsere Nutzer zu entwickeln, zu verstehen, welche Bedürfnisse sie haben und wie wir als Produktentwickler ihr Leben verbessern können.
Doch selbst wenn die in der Story benannte Person ein echter User ist, wirken User Stories häufig leblos und uninspiriert. Teilweise werden nicht einmal Personas recherchiert, sondern im besten Fall zwischen Bestands- und Neukunden unterschieden, und im Backlog liegt ein Haufen von Stories, die alle mit „Als User“ beginnen. Genauso wird die Frage „was möchte der Nutzer“ häufig gar nicht ergebnisoffen gestellt, sondern interne Ideen als „Kundenwunsch“ verpackt („das ist jetzt der neueste Schrei“).
Als Studentin möchte ich auf dem Weg von Vorlesung zu Vorlesung einen Milchshake trinken, damit ich keinen Hunger mehr habe.
Doch warum gerade ein Milchshake? Und wie wichtig ist das eigentlich verglichen mit den anderen User Stories im Backlog? Wenn die User Story nur eine leere Hülle ist, die irgendwie befüllt werden muss, dann entstehen zwar schlankere, aber immer noch steife Anforderungsdokumente, die im Wesentlichen einer zerstückelten Wasserfalldokumentation ähneln. Ihren eigentlichen Zweck – nämlich die Anforderungen in den Kontext der Kundenbedürfnisse zu setzen – verfehlen die User Stories im Projektalltag leider oft. Was können wir also anders machen?
Alan Klement begründete mit Jobs To Be Done (JTBD) eine Methode zur Produktentwicklung. Für Klement ist ein Job nicht einfach nur ein Task oder eine Handlung. Stattdessen stellt ein Job ein Bedürfnis nach Fortschritt dar:
1. Es gibt eine gewisse Art zu leben/arbeiten
2. Es gibt eine neue, bessere, erstrebenswerte Art zu leben/arbeiten
3. Es gibt Hindernisse, die dich davon abhalten von 1. zu 2. zu gelangen.
Wenden wir uns diesen drei Punkten einmal im Detail zu: Zunächst geht es um die Situation in der sich unsere Nutzer befinden. Dazu sollte die Situation möglichst genau beschrieben werden, denn wie bei der User Story versuchen wir, Empathie zu schaffen. Die Identität des Nutzers spielt dabei nur eine untergeordnete Rolle. Nutzer in Gruppen einzusortieren ist im besten Falle eine Vereinfachung ihrer komplexen Bedürfnisse, im schlechtesten Fall eine Verzerrung und die Persona schlägt in eine Karikatur voller Vorurteile um.
Wenn ich Hunger habe, dann …
Wir alle kennen diese Situation. Aber wissen wir bereits, wie sich unsere Nutzerin oder unser Nutzer fühlt? Besser wäre
Wenn ich gestresst von einem Meeting zum nächsten renne, heute noch nichts gegessen habe und nur eine Hand frei, weil ich eine schwere Laptoptasche mit mir herumtrage, dann …
Es spielt keine Rolle, ob wir selbst bereits in dieser Situation waren, eine solche Beschreibung erzeugt ein Bild vor unserem inneren Auge und gibt uns die Möglichkeit, echte Empathie zu entwickeln.
Der zweite Punkt beschreibt das erhoffte Ergebnis: Wir versuchen uns vorzustellen, wie die Welt aussehen würde, wenn das Problem gelöst wäre. Für das obige Beispiel könnte dieser erstrebenswerte Zustand vielleicht so aussehen:
Ich komme pünktlich zu meinem nächsten Meeting, fühle mich wieder voller Energie und kann den ganzen Tag über mein Leistungsniveau halten.
Der dritte und letzte Punkt ist der vielleicht interessanteste. Im Gegensatz zur klassischen Userstory geht es in erster Linie nicht darum, die Lösung konkret zu benennen (obwohl das in trivialen Fällen durchaus möglich ist). Stattdessen beschäftigen wir uns damit, das Problem zu verstehen. Was sind die Hindernisse, die unsere Kunden daran hindern, von ihrer aktuellen Situation in die gewünschte zu gelangen. Unser Ziel ist es, die Eigenschaften, die eine Lösung mitbringen muss, zu benennen, die Beweggründe, die den Nutzer dazu bringen, unsere Lösung zu nutzen. Kurz gesagt: Seine Motivation, sich in unsere Hände zu geben, statt in die eines Mitbewerbers.
Ich möchte etwas, das ich mit einer Hand im Laufen essen kann und das nicht kleckert.
Gießt man diesen Ansatz nun in Template, ähnlich der User Story, so ergibt sich folgender Aufbau:
Wenn <Situation>,
möchte ich <Motivation>,
damit <Erwartetes Ergebnis>.
Wenn ich gestresst von einem Meeting zum nächsten renne, heute noch nichts gegessen habe und nur eine Hand frei, weil ich eine schwere Laptoptasche mit mir herumtrage, dann …
möchte ich etwas, das ich mit einer Hand im Laufen essen kann und das nicht kleckert,
damit ich pünktlich zu meinem nächsten Meeting komme, mich wieder voller Energie fühle und über mein Leistungsniveau den ganzen Tag halten kann.
Was wir nun vor uns haben, ist eine Grundlage für eine ergebnisoffene Diskussion. Wir haben ein gemeinsames Verständnis für die Randbedingungen und Bedürfnisse unserer Kunden geschaffen, und geben dem Entwicklungsteam damit die Möglichkeit, selbstständig eine Lösung zu erarbeiten. Die Job Story ist damit keine Zusammenfassung der detaillierten Feature-Beschreibung, die sowieso im Laufe der Entwicklung (spätestens bei der Dokumentation) geschrieben werden muss, sondern eine Momentaufnahme der Ausgangssituation aus der das Feature erwachsen ist, und kann damit jederzeit zu Rate gezogen werden, wenn es darum geht, zu entscheiden, wie Features zu priorisieren sind.
Zum Abschluss möchte ich noch zwei häufige und völlig verständliche Einwände gegen diese Art der Anforderungsbeschreibung würdigen. Insbesondere in Projekten, in denen die Anforderungen streng und klar definiert sind, in denen das Entwicklungsteam Lösungen nicht selbst konzipiert, sondern Features außerhalb des Teams erarbeitet werden, erscheint der Aufwand zur Erstellung einer guten Job Story unsinnig und der Nutzen fragwürdig. Genau an dieser Stelle hat aber auch das Schreiben einer User Story salopp gesagt keinen Sinn. Job Stories und User Stories sind Hilfsmittel, um Anforderungen zu erarbeiten, und stehen damit am Anfang der Lösungskonzeption, nicht am Ende. Wenn das Team sowieso nur streng definierte Features umsetzt, dann ist eine detaillierte Beschreibung der Anforderungen völlig ausreichend. Identität des Nutzers und Zweck des Features sind vollkommen unwichtig.
Wer hingegen bereits langjährige Erfahrung in der Verwendung von User Stories bei der Konzeption von Lösungen hat, wer in einem erfolgreichen, kompetenten und selbstständigen Team arbeitet, mag einwenden, dass all die oben beschrie benen Ziele sich genauso auch mithilfe von User Stories (und detaillierten Personas) erreichen lassen. Jedem, der diese Erfahrung gemacht hat, kann ich nur gratulieren: Du und dein Team habt das Agile Mindset anscheinend bereits tief verinnerlicht. Doch insbesondere auf Projekten, bei denen häufig neue Kolleginnen und Kollegen dazustoßen, hat die Job Story einen positiven Nebeneffekt: Wir müssen uns jedes Mal aufs neue mit dem Kunden auseinandersetzen, statt uns auf einer im Voraus (vielleicht sogar vor Beginn unserer Tätigkeit) konzipierten Persona ausruhen zu können.
Wie so oft in der agilen Entwicklung geht es in Wahrheit gar nicht um die Tools und Prozesse, sondern um das Mindset, mit dem diese angewandt werden. Mit der richtigen Einstellung sind Templates einfach nur Hilfsmittel, die unser Leben vereinfachen. Wie jedes neue Konzept kann uns die Job Story helfen, alte Denkmuster aufzubrechen. Allein die Existenz eines weiteren Werkzeuges in unserem Koffer sorgt dafür, dass wir uns fragen, welches Tool das richtige für uns ist. Wir beschäftigen uns damit, warum wir Dinge so formulieren, wie wir es tun, und denken darüber nach, ob wir es nicht besser machen könnten. Wenn wir Verständnis für unsere Kunden haben, dann werden wir mit Hilfe von “ganz normalen” User Stories tolle Features konzipieren. Sind wir faul und desinteressiert, dann werden auch Job Stories uns nicht helfen, zu erkennen, was unsere Nutzer brauchen.