Leitfaden für User Storys.

Eine User Story ist ein Instrument, das in der agilen Software-Entwicklung verwendet wird, um das Endanwendererlebnis darzustellen. Anstatt die Entwicklungs-Teams zu bitten, ein einziges großes Projekt zu erstellen, werden große Projekte in handhabbare kleinere Schritte unterteilt, die sich besser verwalten lassen. Dies unterstützt agile Teams letztlich dabei, häufig auftretende Probleme hinsichtlich der Formatfestlegung, Zusammenarbeit, Flexibilität und Dynamik zu vermeiden.

User Storys sind ein nützliches Instrument, mit dem ihr sicherstellen könnt, dass alles, was ihr entwickelt, nicht nur auf technische Details ausgerichtet ist, sondern auch einen Mehrwert für Endanwenderinnen und Endanwender bietet. Diese User Storys sorgen für ein einheitliches Verständnis unter den Projektbeteiligten, sodass alle auf das gleiche Ziel hinarbeiten.

In diesem Leitfaden wird erläutert, wie User Storys funktionieren, warum sie von Vorteil sind und wie ihr User Storys für eure Teams schreiben könnt.

In diesem Artikel geht es um folgende Themen:

• Was sind User Storys?
• User Story und Use Case im Vergleich.
• Vorteile von User Storys.
• Wer sollte User Storys schreiben?
• User-Story-Lebenszyklus.
• So schreibt ihr User Storys.
• Vorlagen und Beispiele für User Storys.
• So fügt ihr Details zu User Storys hinzu.

Was sind User Storys?

Eine User Story ist ein Instrument für die Entwicklung, mit dem Features oder Funktionen aus Endanwender- oder Kundenperspektive erklärt werden. Agile Teams schreiben User Storys auf Haftnotizen oder Karteikarten und tracken sie auf einem Whiteboard oder mit einem digitalen Kanban-Board, um den Fortschritt zu überwachen.

Der Zweck einer User Story besteht darin, eine sehr einfache und klare Beschreibung der einzelnen Anforderungen zu verfassen. Anstatt sich auf die technischen Details zu konzentrieren, fokussiert sich euer Team mithilfe von User Storys auf das, worauf es eigentlich ankommt: das Endanwendererlebnis.

Erstmals erwähnt wurden User Storys 1999 in dem Buch Extreme Programming Explained von Kent Beck. Im Jahr 2001 erweiterte Ron Jeffries das von Beck formulierte Konzept der User Storys, indem er es um das 3-C-Framework – „Card“, „Conversation“ und „Confirmation“ – ergänzte. 2003 entwickelte Bill Wake dann die INVEST-Checkliste, um Teams einprägsame Richtlinien zum Schreiben effektiver User Storys zu bieten. Auch wenn es Wake war, der das Akronym einführte, fand die Checkliste erst mit dem Buch User Stories Applied: For Agile Software Development von Mike Cohn aus dem Jahr 2004 umfassende Verbreitung.

Selbst als sie sich in Entwicklerkreisen durchsetzten, wurden User Storys absichtlich informell gehalten. Sie werden auf Karteikarten oder Haftnotizen geschrieben, um die Planung und Diskussion zu erleichtern. Ästhetik spielt dabei keine Rolle. Stattdessen stehen bei User Storys Inhalt und Funktion im Vordergrund.

Heute orientieren sich Entwickelnde an dem Akronym INVEST, um umsetzbare User Storys zu schreiben:

• Independent. Jede User Story sollte unabhängig von anderen Storys sein. Auf diese Weise kann das betreffende Team in beliebiger Reihenfolge an den User Storys arbeiten. Außerdem wirken sich Änderungen an einer Story nicht auf die anderen Storys aus.
• Negotiable. User Storys sind nicht in Stein gemeißelt. Diese Storys sind iterativ und sollten sich ändern, sobald dem Team mehr Informationen zur Verfügung stehen.
• Valuable. Letztendlich soll das Produkt, das ihr entwickelt, Endanwenderinnen und Endanwendern einen Mehrwert bieten. Wenn eine Story keinen Mehrwert bietet, lohnt sich der Aufwand dafür voraussichtlich nicht.
• Estimable. Ihr solltet in der Lage sein, den Umfang einer User Story grob abzuschätzen, damit ihr wisst, wie ihr die Arbeit priorisieren und planen könnt.
• Small. Haltet die User Storys so klein, dass die Entwickelnden sie innerhalb einer einzigen Iteration, in der Regel also innerhalb von drei Tagen, programmieren und testen können.
• Testable. Für jede User Story sollte es klare Kriterien geben, anhand derer sich feststellen lässt, ob sie für die Anwenderinnen und Anwender geeignet ist oder ob sie geändert werden muss.

User Story und Use Case im Vergleich.

Sowohl User Storys als auch Use Cases sind hilfreiche Instrumente für Entwickelnde, um Systemanforderungen zu definieren. Allerdings dienen sie unterschiedlichen Zwecken. Beide Konzepte beschreiben das Anwendererlebnis, aber die Begriffe sind nicht synonym. Ivar Jacobson entwickelte in den 1980er-Jahren das Konzept der Use Cases, um das Verhalten eines Systems und die Abfolge der erforderlichen Interaktionen zwischen einer Anwenderin bzw. einem Anwender und dem System zu beschreiben.

In einem Use Case werden oft zusätzliche Schritte beschrieben, beispielsweise die Vorbedingungen, die erfüllt sein müssen, bevor der Use Case ansetzen kann. User Storys hingegen sind kurze, einfache Beschreibungen, die sich auf den Kern der jeweiligen Anwenderanforderung konzentrieren. Sie sind weniger detailliert als Use Cases und dienen eher dazu, den Austausch und die Zusammenarbeit zu erleichtern.

Vorteile von User Storys.

Wenn große Projekte in kleinere User Storys unterteilt werden, ist es für Teams viel einfacher, komplexe Projekte zu bewältigen. User Storys unterstützen agile Entwicklungs-Teams außerdem bei Folgendem:

1. Vermeidung von Verwirrung durch Verwendung eines einfachen Formats. User Storys sind knapp gehalten und nicht technisch, d. h. jeder kann sie verstehen. Dieses vereinfachte Format sorgt für weniger Komplexität und vermittelt allen Beteiligten ein klares Verständnis für die Anwenderanforderungen.
2. Fokussierung auf die Anwenderinnen und Anwender. User Storys unterstützen Entwickelnde dabei, sich weniger auf die Funktionen und mehr auf den eigentlichen Zweck einer Lösung zu konzentrieren, nämlich die Unterstützung der Endanwenderinnen und Endanwender.
3. Ermöglichung von Zusammenarbeit. User Storys erleichtern den Team-Mitgliedern die Zusammenarbeit, indem sie die Anwenderbedürfnisse klären und so den Entwicklungsprozess straffen.
4. Förderung kreativer Lösungen. User Storys geben keine Lösung vor, sondern konzentrieren sich auf ein Bedürfnis. Dadurch erhalten Entwickelnde die Freiheit, über den Tellerrand hinauszuschauen und innovativere Lösungen zu entwickeln, die die Anwenderbedürfnisse bestmöglich erfüllen.
5. Erhöhung der Flexibilität. User Storys sind unglaublich flexibel und bieten euch den Spielraum, sie anzupassen, sobald ihr mehr über die Lösung oder die Anwenderbedürfnisse erfahrt. Dies ermöglicht es agilen Teams, sich auf Veränderungen einzulassen und sich anzupassen, wenn sich etwas ändert.
6. Entwicklung von Dynamik. Da sie klein und umsetzbar sind, ermöglichen User Storys eine schrittweise Entwicklung und stetige Fortschritte für euer Team. Entwickelnde können ihre Fortschritte in Echtzeit verfolgen, was die Dynamik eures Teams noch verstärkt.

Wer sollte User Storys schreiben?

User Storys werden üblicherweise in der Planungsphase eines Projekts geschrieben. Mitunter ist es jedoch notwendig, User Storys zu bearbeiten oder zu ergänzen, wenn neue Funktionen hinzukommen oder sich die Anforderungen ändern.

Technisch gesehen kann jeder User Storys schreiben. Aber in der Regel sind die Produktverantwortlichen für die Erstellung und Verwaltung der User Storys zuständig. Da sie für die Umsetzung der Produktvision zuständig sind, verfassen die Produktverantwortlichen die ersten User Storys. Im Laufe des Projekts können auch Mitglieder des Entwicklungs-Teams User Storys beisteuern, insbesondere dann, wenn sie große technische Schritte in überschaubarere Storys aufteilen müssen.

Nicht selten bringen auch Stakeholder wie Kundinnen und Kunden oder sogar die Geschäftsleitung User Storys ein, obwohl üblicherweise die Produktverantwortlichen das letzte Wort haben.

User-Story-Lebenszyklus.

Jede User Story durchläuft während eines Software-Projekts sechs Phasen.

1. „Pending“ (Ausstehend).

In dieser Phase identifiziert ihr die User Storys, indem ihr eine kurze Beschreibung dazu verfasst. Zu diesem Zeitpunkt gibt es noch keine detaillierten Anforderungen. In dieser Phase befindet sich die Story in einem Backlog, bis das Team sie bearbeitet oder verwirft.

2. „To-do“ (Aufgabenverteilung).

Sobald sich das Team für eine Story entschieden hat, fügt es sie seiner Aufgabenliste hinzu, d. h. die Story ist bereit für die Umsetzung. In dieser Phase ordnet das Team die zu erledigenden Aufgaben einem Sprint zu und fügt sie zu seinem Zeitplan hinzu.

3. „Discussing“ (Diskussion).

Um die User Story umzusetzen, muss das Team die Kriterien der Story erörtern. Es entscheidet über Anforderungen, Wireframes und Storyboards, um die Details der User Story auszuarbeiten.

4. „Developing“ (Entwicklung).

In dieser Phase programmiert, testet und integriert das Programmier-Team die Story und stellt sicher, dass die Anwenderanforderungen erfüllt werden.

5. „Confirming“ (Bestätigung).

Dies ist die Testphase. Je nach euren Workflows können auch andere Entwickelnde, Produktverantwortliche oder sogar die Endanwenderinnen und Endanwender die Lösung testen. Ziel ist es, zu bestätigen, dass das Feature die Anforderungen erfüllt. Ist dies nicht der Fall, geht die Story zurück in die Entwicklung, bis die Bestätigung erfolgt.

6. „Finished“ (Abschluss).

In dieser Phase hat die User Story alle Tests bestanden und das Team fügt sie zur nächsten Version hinzu.

So schreibt ihr User Storys.

Bei User Storys liegt der Fokus auf der Einfachheit. Die fünf folgenden Tipps erleichtern es eurem Entwicklungs-Team, einfache, aber nützliche User Storys zu schreiben:

1. Definiert „erledigt“. Eine Story ist in der Regel dann erledigt, wenn die Anwenderin oder der Anwender die beschriebene Aufgabe ausführen kann. Ihr solltet jedoch genau beschreiben, was „erledigt“ bedeutet. Dadurch wird es viel einfacher, die einzelnen User Storys abzuschließen.
2. Erwägt die Erstellung mehrerer Storys. Wenn es um mehrere Endanwenderinnen und Endanwender geht, solltet ihr für sie jeweils eine eigene Story schreiben, um auf alle Bedürfnisse einzugehen.
3. Gliedert Aufgaben und Teilaufgaben. Die Aufteilung eines großen Projekts in kleinere Aufgaben ermöglicht es, Aufgaben zu delegieren und unabhängig zu arbeiten. Das macht es auch viel einfacher, den Fortschritt und die Ergebnisse des Teams zu tracken.
4. Schreibt eine Story für jeden Schritt eines größeren Prozesses. Beinhaltet eine User Story einen komplexen Prozess, unterteilt sie in kleinere Storys. Dadurch landen zwar mehr Haftnotizen auf eurem Board, aber die Arbeit wird dadurch viel überschaubarer.
5. Holt Feedback ein und berücksichtigt es. Bei der agilen Arbeit dreht sich alles um Zusammenarbeit und Iteration. Passt User Storys auf Basis von Feedback und Daten an, um letztendlich ein qualitativ hochwertigeres Produkt zu entwickeln.

Es ist zwar hilfreich zu wissen, wie User Storys geschrieben werden, aber wenn ihr diesbezüglich noch keine Erfahrung habt, mag das schwierig erscheinen. Im Folgenden haben wir daher einige Beispiele aus der Praxis für gute User Storys aufgeführt.

Vorlagen und Beispiele für User Storys.

User Storys werden oft mithilfe einer einfachen Vorlage formuliert und sind wie folgt aufgebaut: „Als [Anwendertyp] [möchte] ich, [damit].“ Der Teil „Anwendertyp“ gibt an, wer eure Endanwenderinnen und Endanwender sind, seien es vielbeschäftigte Eltern, die online Babykleidung einkaufen, oder Geschäftsleute, die eine Buchhaltungs-Software benötigen. Der Teil „möchte“ geht auf die Features ein, die der betreffende Anwendertyp sich wünscht, und der Teil „damit“ erklärt den Grund, warum das Feature für den Anwendertyp wichtig ist.

Beispiele:

• Als [Restaurantbesitzer] möchte ich [die Angebote in meiner Online-Speisekarte täglich aktualisieren], sodass [sich die Gäste über die aktuellen Angebote informieren können, ohne im Restaurant anzurufen].
• Als [registrierte Anwenderin] möchte ich [mein Passwort zurücksetzen können], damit [ich auf mein Konto zugreifen kann, ohne den Kunden-Service zu kontaktieren].
• Als [Online-Kunde] möchte ich [Produkte nach Preis filtern], damit [ich schnell die Produkte finden kann, die meinen Preisvorstellungen entsprechen].

Diese Struktur ist zwar nicht erforderlich, erleichtert es euch jedoch, zu definieren, wann eine User Story „erledigt“ ist. Wenn die Lösung den Mehrwert erfasst, den der Anwendertyp wünscht, könnt ihr die Story als erledigt betrachten.

So fügt ihr Details zu User Storys hinzu.

Ihr wisst nun, wie effektive User Storys geschrieben werden. Aber möglicherweise hapert es noch bei den Details. Es gibt zwei Möglichkeiten, User Storys mit Details zu versehen: Entweder wird die User Story in eine kleinere Storys aufgegliedert oder es werden Akzeptanzkriterien mit den „3 C“ hinzugefügt.

So ist beispielsweise die User Story „Als [Marketing Manager] möchte ich [Änderungen an meinen Blogs in der Vorschau anzeigen], damit [ich sicherstellen kann, dass sie korrekt dargestellt werden]“ aus Entwicklungsperspektive zu allgemein gehalten. Gliedert sie in eine kleinere User Story auf, beispielsweise „Als [Marketing Manager] möchte ich [einen Vorschaubereich im Blog-Publisher haben], damit [ich eine Vorschau der Blog-Inhalte sehen kann, bevor sie veröffentlicht werden]“.

Mit den „3 C“ könnt ihr eure User Storys außerdem verfeinern:

1. Card. Dies ist die schriftliche User Story, die der knappen schriftlichen Vorlage „Als [Anwendertyp] [möchte] ich, [damit]“ folgt. In dieser Phase ist die Story lediglich eine Erinnerung ohne viele Details.
2. Conversation. Dies ist die Diskussion zwischen dem Team, den Anwenderinnen und Anwendern und den Produktverantwortlichen. Im Mittelpunkt stehen der konkrete Mehrwert für die Endanwenderinnen und Endanwender sowie detailliertere technische Informationen und Testanforderungen.
3. Confirmation. Während der Bestätigungsphase einigt sich das Team auf Akzeptanzkriterien, die Auskunft darüber geben, wann eine Story erledigt ist. Dadurch werden Unklarheiten beseitigt und es wird deutlich, ob ihr die Vorgaben erfüllt habt oder nicht.

Unkomplizierte Unterstützung für User Storys.

User Storys ermöglichen es Entwicklungs-Teams, große, schwer überschaubare Projekte in umsetzbare Aufgaben zu unterteilen. Sie sorgen dafür, dass keine Verwirrung entsteht und dass agile Teams Lösungen entwickeln, die Endanwenderinnen und Endanwendern Mehrwert bieten.

Wenn ihr bereit seid, loszulegen, solltet ihr Lösungen erkunden, die euch dabei unterstützen, die Erwartungen eurer Anwenderinnen und Anwender zu übertreffen. Adobe Workfront macht eure Ziele sichtbar, sodass euer Team die Arbeit priorisieren, den Fortschritt tracken und die Ergebnisse messen kann. Die All-in-One-Lösung ermöglicht es euch, User-Storys, Sprint-Fortschritte und Burndown-Charts über ein intuitives Dashboard anzuzeigen.

Startet eine Produkttour zu Adobe Workfront oder seht euch ein Übersichtsvideo an, um mehr zu erfahren.