Agile Projekte: User Stories – und warum sie so wichtig sind

von Philip Schaffner

Zusammen mit den Begriffen "agile", "Scrum" und "Kanban", die nun seit vielen Jahren allgegenwärtig sind in der IT Welt, ist auch der Begriff der "User Story" aufgekommen. User Stories sind die beliebteste Art, Anforderungen in agilen Projekten zu erfassen. In den Grundzügen ist die Verwendung von User Stories eine einfache Sache. Aber wozu dient sie genau? Und was macht eine gute User Story aus? 

Inhaltsübersicht:

• Elemente einer Story
• Qualitätsmerkmale einer User Story
• Beispiele aus der Praxis
• User Stories sind ein Work Product

Die Form einer User Story ist nicht vorgegeben, aber es hat sich eingebürgert, eine Vorlage zu verwenden, um sicherzugehen, dass wir die wichtigsten Aspekte abdecken:

• Für wen bauen wir, wer ist der Benutzer -> In meiner <Rolle> als...
• Was wollen wir erzielen, was ist die Absicht??-> Ich will <ein Wunsch oder ein Ziel>
• Warum bauen wir, weshalb wird etwas gebraucht, welchen Wert hat es für den Anwender? -> So dass <Nutzen,Wert>

Eine User Story sieht deswegen meist etwa so aus: „Als <Rolle> möchte ich <Wunsch/Ziel>, so dass <Nutzen>.“ Eigentlich keine Hexerei! Doch wie immer liegt der Teufel im Detail. Und mit der Zeit zeigen sich in den meisten Projekten Tücken bei der Verwendung von User Stories. Viele sind auf die Formulierung dieser Stories zurückzuführen.

Elemente einer Story

So einfach sie aussehen, sollten wir uns doch erst einmal kurz Gedanken machen, wofür die Platzhalter in der Story-Grundform stehen.

Rolle: Eine User Story beinhaltet immer eine relevante Rolle, die definiert, welcher Stakeholder in welcher Kapazität den Bedarf ausdrückt. Typischerweise werden Rollen aus der Anwendungsdomäne der Software übernommen. Im ERP-Bereich könnten das z.B. Account Manager, Einkäufer oder Vertriebsmitarbeiter sein. Ein alternativer Ansatz ist die Verwendung von Personas, die als fiktive Charaktere bezeichnet werden und eine archetypische Gruppe von Benutzern darstellen. Wichtig ist in jedem Fall, dass die Rolle wohldefiniert ist und sich jeder Beteiligte eine konkrete Person mit all ihren Facetten darunter vorstellen kann, um eine plastische Vorstellung der Anforderung zu haben.

Wunsch/Ziel: Hier können unterschiedliche Strukturen vorkommen, da User Stories verschiedene Arten von Anforderungen abbilden wollen. Aus grammatikalischer Sicht haben Ziele drei Elemente:

1. ein Subjekt mit einem Ziel wie "wollen" oder "können",
2. ein Aktionsverb, das die Aktion im Zusammenhang mit dem angeforderten Merkmal ausdrückt,
   und
3. ein direktes Objekt, auf dem die Rolle die Aktion ausführt.

Nutzen: Zusammen mit der Anforderung geben wir noch eine Erklärung, warum sie gestellt wird. Dies ermöglicht es den anderen Stakeholdern, sich besser in die Rolle hinzuversetzen und zu verstehen, was gebraucht wird.

Qualitätsmerkmale einer User Story

Das "Quality User Story Framework" misst die Qualität einer User Story anhand von 13 Eigenschaften. Diese lassen sich in drei Kategorien aufteilen:

Die syntaktischen Eigenschaften stellen sicher, dass die Story richtig formuliert ist:

• 1.1 Wohlgeformt: Eine User Story enthält mindestens eine Rolle und ein Ziel.
• 1.2 Atomar: Eine User Story drückt eine Anforderung für genau ein Feature aus.
• 1.3 Minimal: Eine User Story enthält nichts weiter als Rolle, Ziele und Nutzen.

Die semantischen Kriterien sollen sicherstellen, dass die Zusammenhänge und die Bedeutung der einzelnen Teile der User Story korrekt sind:

• 2.1 Konzeptuell fundiert: Das Ziel drückt eine Eigenschaft der Software aus, der Nutzen entspricht einer Begründung.
• 2.2 Problem-orientiert: Eine User Story spezifiziert nur das Problem, nicht die Lösung.
• 2.3 Eindeutig: Eine User Story vermeidet Begriffe oder Abstraktionen, die zu verschiedenen Interpretationen führen.
• 2.4 Konfliktfrei: Eine User Story sollte mit keiner anderen User Story unvereinbar sein.

Und zum Schluss noch die Kategorie "Pragmatismus". Hier geht es um das subjektive Verständnis der User Story bei der Zielgruppe, unabhängig von Syntax und Semantik:

• 3.1 Ganzer Satz: Eine User Story ist ein wohlgeformter, ganzer Satz.
• 3.2 Schätzbar: Eine Story beschreibt kein grobkörniges Requirement, das schwer zu planen und zu priorisieren ist.
• 3.3 Einzigartig: Jede User Story ist einzigartig, Dubletten werden vermieden.
• 3.4 Einheitlich: Alle User Stories in einer Spezifikation verwenden die gleiche Vorlage.
• 3.5 Unabhängig: Die User Story ist in sich abgeschlossen und hat keine inhärenten Abhängigkeiten zu anderen Geschichten.
• 3.6 Komplett: Die Implementierung einer Reihe von User Stories erzeugt eine komplette Anwendung, es fehlen keine Schritte.

Das klingt jetzt alles sehr sinnvoll und naheliegend. In der Praxis braucht es aber viel Aufmerksamkeit und Disziplin, diese Grundsätze immer im Hinterkopf zu behalten.

Beispiele aus der Praxis

Wenn eine User Story nicht gut geschrieben ist, können bei der weiteren Bearbeitung der User Stories Probleme auftreten. Im Folgenden wird eine Reihe von Beispielen aus der Praxis vorgestellt – inklusive Kurzüberlegungen, was daran nicht optimal ist.

• "Ich möchte einen Fehler sehen, wenn ich nach dem Hochladen eines Artikels keine Empfehlungen sehen kann.": Ist nicht wohlgeformt, es fehlt die Rolle. Wen betrifft sie, wer möchte diesen Fehler sehen? Es ist immer wichtig, die Grundstruktur einzuhalten und auch diese Story zu beginnen mit "Als Administrator..." oder "Als Benutzer..."
• "Als Benutzer kann ich einen bestimmten Ort auf der Karte anklicken und so eine Suche nach Sehenswürdigkeiten durchführen, die mit diesen Koordinaten verbunden sind.": Ist nicht atomar, der Nutzen ist als weitere Anforderung formuliert. Einerseits fehlt uns hier eine Beschreibung des Nutzens, und andererseits verringern wir so die Genauigkeit unserer Schätzung. Stattdessen müssten daraus zwei Stories werden: 1. "Als Benutzer kann ich einen bestimmten Ort auf der Karte anklicken". 2. "Als Benutzer kann ich Sehenswürdigkeiten sehen, die mit den Koordinaten eines bestimmten Ortes verbunden sind."
• "Als Pflegeexperte möchte ich die registrierten Stunden dieser Woche sehen (aufgeteilt in Produkte und Aktivitäten). Siehe: Mockup von Alice. ANMERKUNG - Erstelle zuerst den Übersichtsbildschirm und füge dann Validierungen hinzu.": Eine User Story, die minimal ist, enthält nur Rolle, Ziel und Nutzen. Die hier erwähnten Zusatzinformationen wie der Mockup und die Herangehensweise können in separaten Attributen (z.B.. Beschreibung) untergebracht werden, haben aber in der Story nichts zu suchen. Dies hilft uns, Ordnung zu halten und vor allem sicherzustellen, dass wir das "was", das "warum" und das "wie" klar trennen. Denn wenn jetzt beispielsweise auf dem Mockup von Alice Produkte und Aktivitäten zusammengefasst werden, haben wir hier direkt einen Widerspruch - der im besten Fall auffällt und aufgelöst wird, im schlechtesten Fall zu einem Defect und Rework führt.
• "Als Pflegeexperte möchte ich eine Rückerstattung erfassen - "Speichern"-Button oben rechts (nie ausgegraut).": Eine User-Story sollte nur das Problem spezifizieren (-> Problem-orientiert). Falls unbedingt erforderlich, können Implementierungshinweise als Kommentare oder Beschreibungen aufgenommen werden. Neben der Verletzung des "Minimal"-Qualitätskriteriums enthält dieses Beispiel Implementierungsdetails (eine Lösung) innerhalb des User-Story-Textes. Damit nehmen wir das "wie" in dem "was" vorweg, was unsere Kreativität und Freiheit einschränkt und potentiell bessere Lösungen erschwert.
• "Als Benutzer kann ich die Inhalte bearbeiten, die ich der Profilseite einer Person hinzugefügt habe.": Mehrdeutigkeit ist der natürlichen Sprache eigen, aber der Requirements Engineer, der User Stories schreibt, muss sie so weit wie möglich vermeiden. Eine User Story sollte nicht nur intern eindeutig sein, sondern auch in klarer Beziehung zu allen anderen User Stories stehen. In diesem Beispiel ist nicht klar, wofür "Inhalte" stehen und was mit bearbeiten gemeint ist. Hier wären mehrere Stories nötig, die sich den verschiedenen Arten von Inhalten annehmen.
• Konflikte können sich ebenfalls durch Mehrdeutigkeiten ergeben. Wenn nicht genau definiert ist, was "bearbeiten" bedeutet, widersprechen sich die folgenden beiden Anforderungen potentiell: "Als Benutzer bin ich in der Lage, jede beliebige Sehenswürdigkeit zu bearbeiten." und "Als Benutzer kann ich nur die Sehenswürdigkeiten löschen, die ich hinzugefügt habe.“ Konflikte bei User Stories deuten meistens darauf hin, dass hier eine Anforderung oder ein Prozess noch nicht komplett durchdacht worden ist und der Requirements Engineer gefordert ist, hier Klarheit zu schaffen.
• "Als Betreuer möchte ich meine Routenliste für die nächsten/zukünftigen Tage sehen, damit ich mich vorbereiten kann (z.B. kann ich sehen, wann ich mit der Reise beginnen sollte).": Ist kaum schätzbar, da nicht klar ist, was eine Routenliste sein sollte. Während dies nur eine ungeordnete Liste von Orten sein kann, zu denen man während eines Arbeitstages geht, ist es ebenso wahrscheinlich, dass die Funktion die Routen algorithmisch ordnet, um die zurückgelegte Wegstrecke zu minimieren und/oder die Route auf einer Karte anzuzeigen. Diese vielen Funktionalitäten verhindern eine genaue Schätzung und erfordern eine Aufteilung der User Story in mehrere User Stories, zum Beispiel: "Als Care Professional möchte ich meine Routenliste für die nächsten/zukünftigen Tage sehen, damit ich mich vorbereiten kann.“ Oder: "Als Manager möchte ich eine Routenliste für Pflegepersonal hochladen."
• "Als Administrator erhalte ich eine E-Mail-Benachrichtigung, wenn ein neuer Benutzer registriert ist.": Ist nicht uniform, da das Ziel keinen Wunsch enthält (...möchte ich...). Die Einhaltung einer gleichen Form erlaubt es, einfach zwischen Anforderungen, Restriktionen und Zusatzinformationen zu unterscheiden.
• Das Kriterium der Unabhängigkeit ist kaum je vollständig einzuhalten, sollte aber immer angestrebt werden. Wenn wir zum Beispiel diese beiden Stories anschauen: "Als Administrator kann ich eine neue Person zur Datenbank hinzufügen." Und:"Als Besucher kann ich das Profil einer Person einsehen." Hier ist auf den ersten Blick klar, dass man das Profil einer Person nur einsehen kann, wenn diese auch der Datenbank hinzugefügt wurde. Solche Abhängigkeiten lassen sich in einem Projekt kaum vermeiden. Umso wichtiger ist es, dass sie, wenn sie auftreten, explizit markiert werden. Dies kann durch eine Bemerkung, Beschreibung oder eine direkte Dependency passieren.

User Stories sind ein Work Product

Gute User Stories sind die Basis für eine erfolgreiche Implementierung. Wir haben hier in aller Kürze 13 Qualitätsmerkmale betrachtet, die nicht trivial umzusetzen sind und in der Hektik des täglichen Betriebs oft leiden. Es ist deswegen wichtig, sich bewusst zu sein, dass User Stories genau wie andere Arbeitsprodukte gegengelesen und korrigiert werden müssen. Es braucht viel Übung und Auseinandersetzung mit der Materie, bis man gute User Stories aus dem Handgelenk schüttelt. Und bis dahin lohnt es sich oft, einmal vier Augen darüber wandern zu lassen oder sich mit einer Checkliste hinzusetzen und Schritt für Schritt nach Verbesserungspotenzial zu suchen.

Literaturhinweis:

Lucassen, G. ,Dalpiaz, F., van der Werf, J.M.E. and Brinkkemper, S., 2015, August. Forging high-quality user stories: towards a discipline for agile requirements. In Requirements Engineering Conference (RE), 2015 IEEE 23rd International (pp. 126-135). IEEE.