Im Jahr 2003 erarbeitete Bill Wake die INVEST-Checkliste, die Teams eine einprägsame Reihe von Richtlinien zum Schreiben überzeugender User Storys an die Hand gibt. Obwohl das Akronym auf Wake zurückgeht, verdankt die Checkliste ihre Popularität Mike Cohns Buch User Stories Applied: For Agile Software Development von 2004.
Selbst als sie sich in Entwicklerkreisen durchsetzten, wurden User Storys absichtlich informell gehalten. Sie wurden meist auf Karteikarten oder Haftnotizen geschrieben, um die Planung und Diskussion zu erleichtern. Ästhetik spielte dabei keine Rolle. Stattdessen standen Inhalt und Funktion im Vordergrund.
Heute orientieren sich Entwicklerinnen und Entwickler am INVEST-Akronym, um umsetzbare User Storys zu formulieren:
- Independent (unabhängig): Jede User Story sollte von anderen Storys unabhängig sein. So kann das Team in beliebiger Reihenfolge an User Storys arbeiten – mit möglichst wenig Überschneidungen oder Abhängigkeit von anderen Storys. Unabhängige User Storys ermöglichen eine flexible Priorisierung, Entwicklung und Auslieferung. Unabhängige User Storys reduzieren auch die Komplexität bei der Planung.
- Negotiable (verhandelbar): Storys sind kein starrer Vertrag, sondern Ausgangspunkt für Diskussionen. Details werden durch Zusammenarbeit zwischen dem Product Owner und dem Entwicklungs-Team verfeinert. Diese Storys sind iterativ und sollten sich weiterentwickeln, wenn das Team zusätzliche Informationen erhält. Verhandelbare User Storys fördern den kontinuierlichen Dialog und ermöglichen so die Erarbeitung der besten Lösungen. Sie verhindern außerdem die voreilige Festlegung auf bestimmte Implementierungen.
- Valuable (wertvoll): Ziel des Produkts, das ihr entwickelt, ist es, den Endnutzerinnen und -nutzern einen Mehrwert zu bieten. Wenn eine Story keinen Mehrwert bietet, lohnt sich der Aufwand vermutlich nicht. User Storys mit Mehrwert stellen sicher, dass die Entwicklungsarbeit auf sinnvolle Ergebnisse ausgerichtet ist – und nicht auf Features, die weder Nutzenden etwas bringen noch auf die Unternehmensziele ausgerichtet sind.
- Estimable (schätzbar): Ihr solltet in der Lage sein, den Aufwand für eine User Story grob zu schätzen, um die Arbeit effektiv priorisieren und planen zu können. Schätzbare User Storys erleichtern die Planung, Priorisierung und Prognose. Wenn eine Story nicht geschätzt werden kann, bedarf sie wahrscheinlich weiterer Gespräche oder muss in kleinere Teile heruntergebrochen werden.
- Small (klein): Gestaltet User Storys so klein, dass die Entwickelnden sie innerhalb einer einzigen Iteration, in der Regel innerhalb von drei Tagen, programmieren und testen können. Das fördert einen stetigen Arbeitsfluss, ermöglicht schnelleres Feedback, reduziert Risiken und macht den Fortschritt besser sichtbar.
- Testable (testbar): Jede User Story sollte eine klare Reihe von Kriterien liefern, anhand derer sich feststellen lässt, ob sie für die Nutzenden bereit ist oder ob Änderungen erforderlich sind. Testbare User Storys können dem Team helfen, zu wissen, wann sie „fertig“ sind und ob die implementierte Funktionalität nachweislich wie erwartet funktioniert. Damit unterstützen sie auch die Qualitätssicherung.
Der 3C-Prozess und die INVEST-Kriterien greifen ineinander- Die Conversation-Phase ist entscheidend, um sicherzustellen, dass eine Story verhandelbar und schätzbar ist. In der Confirmation-Phase geht es direkt um den Aspekt der Testbarkeit. Die Card sollte ein kleines und unabhängiges Element abbilden, damit eine fokussierte, produktive Diskussion möglich ist. Produkt-Teams können INVEST während der kollaborativen Phasen der 3Cs als Qualitäts-Checkliste nutzen.
Definition von User Personas.
Die Verwendung spezifischer User Personas anstelle von generischen Nutzenden erhöht die Wirkung und Klarheit von User Storys erheblich. Personas sind fiktive Nutzerprofile, die auf der Grundlage von Recherchen über Nutzerinnen und Nutzer erstellt werden, um die verschiedenen Nutzertypen zu identifizieren, die mit einem Produkt interagieren könnten. Sie helfen Teams, Empathie aufzubauen und ein tieferes Verständnis für die Motivationen, Verhaltensweisen und Ziele der Nutzenden zu gewinnen.
Um Personas zu erstellen, führen Teams häufig Nutzerrecherchen durch Umfragen, Interviews und Fokusgruppen durch. Einmal definiert, sollten die Persona-Namen konsequent im „Als [Persona]“-Teil der User Story verwendet werden (z. B. „Als Sarah, die Marketing-Managerin“, nicht nur „Als Managerin“). Diese Genauigkeit hilft sicherzustellen, dass die Story wirklich auf die Bedürfnisse eines gut verstandenen Nutzersegments ausgerichtet ist.
Schlüsselelemente von User Storys.
Eine gut formulierte User Story dreht sich typischerweise um drei Kernelemente, die oft in einer einfachen Satzstruktur ausgedrückt werden:
- Rolle: Diese Komponente definiert die Identität oder Persona der Nutzenden. Es ist wichtig, die Motivationen und Interessen von Nutzenden zu erfassen. Die Verwendung gut definierter User Personas in dieser Phase ist äußerst effektiv, um nachvollziehbare und wirkungsvolle Storys zu erstellen.
- Ziel: Dieser Teil erklärt, was die Nutzenden mit dem Produkt oder einer bestimmten Funktion erreichen wollen. Der Fokus sollte auf der Beschreibung ihrer Absichten und des gewünschten Ergebnisses liegen, statt die Implementierung oder die UI-Elemente im Detail zu beschreiben.
- Nutzen: Dieser entscheidende Teil beschreibt, warum die Nutzenden das angegebene Ziel erreichen wollen. Er betont den Wert, die Vorteile oder die Motivation hinter dem Bedarf der Nutzenden. Er verknüpft die Funktion mit einem übergeordneten Zweck und rechtfertigt so den Entwicklungsaufwand. Entscheidend ist, dass hier echter Nutzer- oder Geschäftswert beschrieben wird – nicht bloße Systemanforderungen, da dabei wichtige Bedürfnisse übersehen werden könnten.
