User Storys – Beispiele und Vorlagen.

Wenn sich euer Team mit dem Framework für Agile-Projekt-Management befasst hat, seid ihr wahrscheinlich auch mit User Storys vertraut. Aber selbst wenn ihr schon eigene User Storys erstellt habt, kann ein Blick auf die Art und Weise, wie andere Unternehmen und Teams dabei vorgehen, wertvolle Anregungen liefern, um eure Kreativität zu beflügeln.

Aus diesem Grund haben wir eine Liste mit 15 Beispielen für User Storys zusammengestellt, um euch einen Eindruck davon zu vermitteln, wie gute User Storys aussehen, und euch neue Ideen für euren eigenen kreativen Prozess zu präsentieren.

In diesem Leitfaden gehen wir auf die folgenden Themen ein:

• Was ist eine User Story?
• Beispiele für User Storys
• Beispiele für User Storys in verschiedenen Medienformaten
• Beispiele für User Storys im Agile-Framework
• Beispiele für User Storys für jede Phase der Customer Journey
• Erste Schritte mit User Storys

Was ist eine User Story?

Eine User Story ist eine kurze, allgemeine Beschreibung eines bestimmten Software-Features, die einfach formuliert und aus Kunden- oder Endanwenderperspektive verfasst ist. Zweck einer User Story ist es, die Customer Journey und die Art und Weise, wie eure Kundschaft mit eurem Produkt interagiert, besser zu verstehen. Einer der Hauptvorteile dieser Storys besteht darin, dass sie den Entwickelnden den Kontext – das „Warum“ – für das vermitteln, was sie gerade erstellen.

Üblicherweise ist eine User Story kurz – in der Regel nur etwa einen Satz lang – und dient dazu, eine Anwenderin oder einen Anwender, eine Aktion sowie ein gewünschtes Ergebnis zu beschreiben. User Storys werden in einfacher, alltäglicher Sprache aus der Anwenderperspektive abgefasst.

Hier ein Beispiel zur Veranschaulichung:

Als Leserin oder Leser möchte ich diesen Adobe-Leitfaden lesen, damit ich mir gelungene Beispiele für User Storys ansehen kann.

Dieses Beispiel folgt der praxiserprobten User-Story-Vorlage. Als [Anwendertyp einfügen] möchte ich [eine bestimmte Aktion nennen], damit ich [Wert oder Ziel identifizieren].

Wie ihr anhand unserer Beispielen sehen werdet, gehen User Storys nicht auf technische Details des Projekts ein. Daher sollte euer Team möglichst kreativ vorgehen, wenn es sich Gedanken darüber macht, wie Anwenderinnen und Anwender mit eurem Produkt interagieren könnten.

Die Erstellung von User Storys muss nicht zwangsläufig ein formaler Prozess sein. Ihr könnt eure einzelnen User Storys einfach auf Karteikarten oder Haftnotizen schreiben. Alternativ könnt ihr sie auch mit digitalen Tools wie Microsoft Word, PowerPoint oder Excel erstellen und organisieren.

Jedes Mitglied eures Agile-Teams kann User Storys erstellen. Letztendlich obliegt es jedoch der oder dem Product Owner, über die User Storys zu entscheiden und sie im Agile-Produkt-Backlog zu priorisieren.

Mit den „3 C“ schöpft ihr das Potenzial eurer User Storys besser aus.

Unabhängig davon, wer die User Storys erstellt, sollten die 3 C berücksichtigt werden:

• Card
• Conversation
• Confirmation

Auf der „Card“ bzw. Karte haltet ihr die User Story fest. Sie steht für die erste Phase, also das erste C bei der Identifizierung der Anwenderanforderungen. Die Karte sollte gerade so viele Informationen enthalten, dass das Team die User Story versteht und die mit der User Story verbundenen Aktionen oder Aufgaben planen kann. Auf einer Karte mit einer User Story sollte immer eine Anwenderin bzw. ein Anwender, eine Aktion und ein Ergebnis aufgeführt sein.

Nach Erstellung der Karte kann euer Agile-Team zum zweiten C übergehen: der „Conversation“. Hier können alle ihrer Kreativität freien Lauf lassen, in die Rolle der Verbraucherinnen und Verbraucher schlüpfen und ihre Anforderungen weiter beleuchten.

Die letzte Phase des 3-C-Modells ist die „Confirmation“, also die Bestätigung. In dieser Phase bewerten die Stakeholder die User Story anhand von Akzeptanzkriterien. Die Verwendung des 3-C-Modells hilft eurem Team, die Kundenperspektive effektiv wiederzugeben und bessere User Storys zu erstellen.

Erleichtert euch die Erstellung von User Storys mithilfe von INVEST.

INVEST ist ein nützliches Akronym, das euch bei der Erstellung guter, aussagekräftiger User Storys unterstützt. Es steht für:

• Independent. Unabhängige Storys verringern die Abhängigkeiten von anderen Features, was bedeutet, dass sie leichter zu testen sind.
• Negotiable. Dies bezieht sich auf die Funktionalität des Features, welche zwischen der Projektverantwortlichen bzw. dem Projektverantwortlichen und dem Team ausgehandelt werden kann.
• Valuable. Das in der User Story beschriebene Feature muss den Endanwenderinnen und -anwendern einen klaren Nutzen bieten.
• Estimable. User Storys, die zu vage formuliert oder zu umfangreich sind, lassen sich nicht abschätzen.
• Small. User Storys sollten in einem einzigen Sprint vom Entwicklungs-Team abgeschlossen werden können.
• Testable. User Storys müssen testbar sein, um zu bestätigen, dass sie abgeschlossen werden können. Die Akzeptanzkriterien sollten einfach und objektiv sein, mit klaren Pass-/Fail-Szenarien.

Durch den Einsatz von Tools wie INVEST und dem 3-C-Modell kann euer Team von den zahlreichen Vorteilen der User-Story-Erstellung profitieren, beispielsweise von der Verbesserung der Zusammenarbeit, der Unterstützung der Backlog-Priorisierung und der Minimierung von Risiken bei der Feature-Erstellung.

Beispiele für User Storys.

User Storys sind ein äußerst vielseitiges Instrument, das eurer Team dabei unterstützen kann, die Vorteile der Agile-Projekt-Management-Methode effektiver zu nutzen. Um diese Vielseitigkeit zu veranschaulichen, haben wir unsere 15 User-Story-Beispiele in drei Kategorien eingeteilt:

• Medienformat
• Element des Agile-Frameworks
• Phase der Customer Journey

Wenn ihr User Storys in euren Agile-Workflow einbindet, könnt ihr das Beispiel für euer Modell heranziehen, das am besten zu den speziellen Anforderungen eures Projekts passt.

Beispiele für User Storys in verschiedenen Medienformaten.

Karteikarten und Haftnotizen sind analoge Klassiker für das Verfassen von User Storys. Heute erweisen sich jedoch auch zunehmend digitale Vorlagen als nützlich und empfehlen sich, je nach euren Präferenzen, möglicherweise eher für euer Team. Digitale User-Story-Karten bieten sich insbesondere für Teams in Remote- oder Hybrid-Arbeitsumgebungen an.

Karteikarte.

Die schlichte Karteikarte ist ein traditionelles Format für das Verfassen von User Storys, das wunderbar unkompliziert ist. Karteikarten können zur Betrachtung und Bearbeitung in der Gruppe herumgereicht und an die Wand gehängt werden. Diese Karten eignen sich auch hervorragend, um schnell Storys zu notieren, wenn ihr Geistesblitze habt.

Anstatt Zeit damit zu verschwenden, ein Programm aufzurufen oder das richtige Microsoft Word-Dokument zu finden, könnt ihr euch Stift und Papier schnappen, um eure Ideen festzuhalten, bevor sie wieder entschwinden.

Hier ein Beispiel für eine User Story, die ihr auf eure Karteikarte schreiben könnt:

Als Projektverantwortlicher möchte ich eine Workflow-Management-Software prüfen, damit ich eine neue Plattform für mein Team auswählen kann.

Karteikarte mit Akzeptanzkriterien.

User Storys enthalten oft Akzeptanzkriterien, die beschreiben, was ihr tun müsst, um das Ziel der Anwenderin bzw. des Anwenders zu erreichen. Wenn ihr die Karteikartenmethode für User Storys anwendet, könnt ihr die Akzeptanzkriterien auf der Rückseite der Karte vermerken.

Bleiben wir beim obigen Beispiel. Während auf der Vorderseite der Karte die User Story aufgelistet ist, stehen auf der Rückseite der Karte die Akzeptanzkriterien, beispielsweise:

• Stellt sicher, dass Anwenderbewertungen und Erfahrungsberichte auf unserer Produktseite veröffentlicht werden.
• Stellt sicher, dass Anwenderbewertungen für unser Produkt in Drittanbieterforen verfügbar sind.
• Beschafft proaktiv neue Anwenderbewertungen durch das Versenden von Feedback-Anfragen an aktuelle Anwenderinnen und Anwender sowie frühere Kundinnen und Kunden.

Auf diese Weise könnt ihr dafür sorgen, dass die Bewertungen zu eurem Produkt leicht zugänglich sind.

Word-Dokument.

Während sich eine Karteikarte in Papierform für die Arbeit vor Ort im Büro anbietet, ist ein gemeinsam genutztes digitales Dokument besser geeignet, um User Storys remote zu entwerfen, zu bearbeiten und anzuzeigen. Es gibt eine Reihe von Vorlagen, die ihr herunterladen könnt, um die Erstellung von User Storys in Word zu vereinfachen. Alternativ könnt ihr auch eigene Vorlagen erstellen.

Sobald ihr eure Vorlage oder Tabelle erstellt habt, könnt ihr prägnante, aber effektive User Storys wie die folgende erstellen:

Als Produktabonnent möchte ich die Möglichkeit haben, meine monatliche Mitgliedschaft mithilfe von Self-Service-Tools zu kündigen.

Excel-Tabellen.

Mit Microsoft Excel könnt ihr eure User Storys ganz einfach zentral organisieren und im Blick behalten. Kommen wir auf die vorherige User Story zurück, die wie folgt lautet:

Als Produktabonnent möchte ich die Möglichkeit haben, meine monatliche Mitgliedschaft mithilfe von Self-Service-Tools zu kündigen.

Neben der User Story und den Akzeptanzkriterien könnt ihr in eurer Excel-Tabelle auch Zellen für andere Informationen einrichten. Beispielsweise könnt ihr die folgenden Zellen einfügen:

• Kosten für Verzögerungen
• Nutzenhypothese
• Zeitliche Kritikalität

Die Aufnahme der Kosten einer Verzögerung in diese User Story für Produktabonnentinnen und -abonnenten könnte beispielsweise aufzeigen, welche Kosten dem Unternehmen entstünden, wenn es nicht umgehend Self-Service-Tools für die Kündigung von Abonnements einführt. Dies kann folgendermaßen formuliert werden:

Eine sechsmonatige Verspätung bei der Implementierung neuer Self-Service-Tools könnte dazu führen, dass uns mehrere Hundert Probeabonnentinnen und -abonnenten entgehen.

Ihr könnt für diese User Story eine Nutzenhypothese formulieren, die wie folgt lautet:

Wenn wir Anwenderinnen und Anwendern die Möglichkeit bieten, sich über Self-Service-Tools abzumelden, sind sie eher bereit, sich für ein Probeabonnement anzumelden, weil sie sich dann nicht „gefangen“ fühlen.

Die Angabe zur zeitlichen Kritikalität für diese User Story könnte etwa so lauten:

Je länger wir mit der Implementierung von Self-Service-Tools warten, desto mehr hochwertige Leads verlassen den Trichter für Probeabonnements.

PowerPoint.

Microsoft PowerPoint stellt eine weitere hervorragende Möglichkeit dar, User Storys zu erstellen und zu präsentieren. PowerPoint ist vor allem dann von Vorteil, wenn ihr plant, eure User Storys vor einem Publikum zu präsentieren, beispielsweise vor einer Gruppe von Stakeholdern.

Der pragmatischste Ansatz bei PowerPoint besteht darin, die User Story, die Akzeptanzkriterien und alle anderen Informationen auf einer einzigen Folie unterbringen zu können. Ihr könnt auf der gleichen Folie auch den Story-Typ (beispielsweise Erstkontakt, Kauf) und eine Wichtigkeitsbewertung angeben.

Ihr könnt User Storys anhand einer numerischen Skala bewerten oder sie einfach als wenig, mäßig oder extrem wichtig einstufen. Alternativ könnt ihr auch Scrum-Punkte vergeben, eine Maßeinheit, mit der der Aufwand für die Fertigstellung einer User Story geschätzt wird.

Ihr habt die Möglichkeit, die User Storys auch nach der Phase der Customer Journey zu klassifizieren, die sie betreffen oder beeinflussen. Hier einige gängige User-Story-Arten:

• User Storys für Registrierungen und Anmeldungen
• User Storys für Käufe
• User Storys für Kundenbindung (beispielsweise Feature-Updates für Mobile Apps, um die Anwenderinteraktion zu fördern)

Ihr könnt unser Beispiel über die Kündigung von Software-Abonnements entweder als Registrierungs- oder als Kauf-Story aufführen. In jedem Fall würde diese User Story auf der Wichtigkeitsskala ganz oben stehen, da sie einen erheblichen Einfluss auf die Kaufabsicht von potenziellen Kundinnen und Kunden hat.

Beispiele für User Storys im Agile-Framework.

User Storys sind Teil des umfassenderen Rahmens des Agile-Frameworks für Projekt-Management und Produktentwicklung. Das Agile-Framework umfasst Epics, Produkt-Features und User Storys sowie Technical Storys. Das User-Story-Format kann auf all diese Elemente im Workflow angewendet werden.

Werfen wir nun einen Blick darauf, wie sich das User-Story-Format auf die einzelnen Elemente anwenden lässt.

Epics.

Epics sind größere Projekte im Rahmen des Agile-Frameworks. Die Fertigstellung eines Epics kann diverse Projekt-Features und eine Reihe von User Storys erfordern, die im Projektverlauf abgeschlossen werden müssen.

Wie User Storys weisen auch Epics ein grundlegendes Format auf, das eine Anwenderin oder ein Anwender, eine Aktion sowie das gewünschte Ergebnis umfasst. Sie sind vergleichsweise kurz. Epics sind jedoch wesentlich weitreichender angelegt, weshalb für jedes Epic mehrere User Storys erstellt werden müssen.

Hier ein Beispiel für ein Epic:

Als Projektverantwortlicher möchte ich eine solide Work-Management-Plattform, die mein Team in die Lage versetzt, die Vorteile der Agile-Methode zu nutzen.

Sobald ihr euer Epic entwickelt habt, könnt ihr spezifischere User Storys erstellen, um eure Ziele zu erreichen. Ihr könnt beispielsweise eine User Story erstellen, um bestimmte Team-Mitglieder und Tools zu identifizieren und um herauszufinden, was sie mit diesen Tools erreichen möchten.

Features.

Um unser Projektverantwortlichen-Epic umzusetzen, müsste das Entwicklungs-Team mehrere Features entwickeln. Wie ihr feststellen werdet, folgt jedes der nachstehenden Beispiele, in denen Features beschrieben werden, dem gleichen Format für Anwenderaktionen und -erwartungen sowie Ergebnisse:

• Als Projektverantwortlicher möchte ich detaillierte Reports und Grafiken abrufen können, damit ich über die Fortschritte meines Teams auf dem Laufenden bleibe.
• Als Projektverantwortlicher möchte ich Tools zur Workflow-Automatisierung, damit ich meine Produktivität und Effizienz steigern kann.
• Als Projektverantwortlicher möchte ich die Zusammenarbeit fördern, damit ich messbare Geschäftsergebnisse erzielen kann.

Diese Feature-bezogenen Ideen unterstützen ein Entwicklungs-Team für Projekt-Management-Plattformen dabei, die Anforderungen seiner Zielgruppe besser zu verstehen. Das Team könnte diese Konzepte darlegen, um die Features und Tools seiner Projekt-Management-Software zu beschreiben.

User Storys.

User Storys sind vom Umfang her vergleichbar mit Produkt-Features. Sie beziehen sich jedoch eher auf das Anwendererlebnis und weniger auf die technische Umsetzung der jeweiligen Aktion.

Beachtet die feinen Unterschiede zwischen diesen Storys und den oben erwähnten Feature-bezogenen Ideen:

• Als Projektverantwortlicher möchte ich detaillierte Reports abrufen können, damit ich Entscheidungsprozesse unterstützen und die Informationstransparenz verbessern kann.
• Als Projektverantwortlicher möchte ich traditionell aufwendige Prozesse automatisieren, damit ich die Belastung für mein Team verringern und die Arbeitsmoral verbessern kann.

In diesen Storys ist der Projektverantwortliche zwar immer noch der Anwender, aber bei der Aktion und dem gewünschten Ergebnis geht es eher um sein Team und darum, positive Erlebnisse bei der Verwaltung der Arbeit zu erzielen.

Technical Storys.

Technical Storys dienen zur Unterstützung von Epics, Features und User Storys, die alle als funktionale Storys klassifiziert werden.

Technical Storys lassen sich in verschiedene Kategorien einteilen:

• Spike Storys  – Diese Storys erfordern Recherchen, um die funktionalen Kundenanforderungen zu erfüllen.
• Refactoring Storys  – Diese Storys werden verfasst, um den Code zu verwalten.
• Infrastructure Storys  – Diese Storys skizzieren die Änderungen oder Ergänzungen, die zur Unterstützung einer funktionalen User Story erforderlich sind.

Hier ein Beispiel für eine Technical Story:

Als Projektverantwortlicher benötige ich eine Plattform mit Tools für maschinelles Lernen und künstliche Intelligenz (Infrastruktur), damit ich die Verwaltungseffizienz durch Automatisierung steigern kann.

Backlog.

Das User-Story-Format kann auch auf das Produkt-Backlog angewendet werden. Bei diesem Ansatz müsst ihr keine neuen Storys erstellen. Stattdessen könnt ihr sie geordnet nach Priorität gruppieren.

So könnte beispielsweise die User Story des Projektverantwortlichen, der sich Reporting-Tools wünscht, mit drei Punkten bewertet werden, während die Story des Projektverantwortlichen, der sich Automatisierungs-Tools wünscht, mit vier Punkten bewertet wird.

In diesem Szenario kann euer Team beschließen, sich zunächst auf die Entwicklung von Reporting-Tools zu konzentrieren, da dies wahrscheinlich weniger Zeit und Ressourcen erfordert.

Beispiele für User Storys für jede Phase der Customer Journey.

Die Anwenderanforderungen ändern sich im Lauf der Customer Journey. Die User Storys, die ihr erstellt, können danach strukturiert werden, an welcher Stelle im Lebenszyklus sich eine Kundin bzw. ein Kunde oder eine Anwenderin bzw. ein Anwender befindet.

Schauen wir uns nun einige Beispiele für User Storys an, die zu verschiedenen Phasen der Customer Journey passen.

Erstkontakt.

In dieser Phase stehen die Anwenderinnen und Anwender noch ganz am Anfang ihrer Customer Journey. Die Fragen, die sie stellen werden, sind daher wahrscheinlich allgemein gehalten und enthalten keine technischen Formulierungen.

Eine User Story in der Erstkontakt-Phase könnte beispielsweise wie folgt aussehen:

Als Software-Entwicklerin benötige ich eine Lösung, die wichtige Projektinformationen zentral erfasst, damit ich effektiver mit meinen Kolleginnen und Kollegen zusammenarbeiten kann.

Registrierung.

In dieser Phase sind die Anwenderinnen und Anwender an einem Produkt oder einer Lösung interessiert und erwägen ernsthaft, sich anzumelden. Doch bevor sie den Schritt wagen, muss euer Team ihre Ziele, Erwartungen und Anforderungen angemessen berücksichtigen. Diese entsprechenden Bedenken können sich auf den Preis, die Anwenderfreundlichkeit, den Komfort bei der Implementierung oder die Sicherheit beziehen.

Eine registrierungsbezogene User Story könnte folgendermaßen aussehen:

Als Software-Entwicklerin möchte ich eine Plattform, die ich praktisch umgehend einsetzen kann, damit ich messbare Effekte bei der Produktivität und den Projektergebnissen erzielen kann.

Kauf.

Wenn ihr eine hohe Conversion Rate anstrebt, muss euer Kauf- und Anmeldeprozess reibungslos sein. User Storys unterstützen euch dabei, diese Probleme proaktiv zu identifizieren, damit ihr die Zahl der Kaufabbrüche minimieren und den Umsatz steigern könnt.

Eure User Story für den Kauf könnte beispielsweise wie folgt aussehen:

Als Projektverantwortlicher möchte ich eine individuelle anwenderbasierte Preisgestaltung mit größerer Wertgenerierung für mein Unternehmen.

Erste Schritte.

Wenn Kundinnen oder Kunden sich entscheiden, euer Plattformangebot zu abonnieren oder sich für eine kostenlose Testversion anzumelden, ist es wichtig, dass ihr für einen reibungslosen Onboarding-Prozess sorgt. Auf diese Weise könnt ihr eure Kundenbindungsquote steigern und die Abwanderung minimieren.

Die Erstellung einer User Story wie der folgenden hilft euch, das Onboarding aus Kundenperspektive zu betrachten:

Als Projektverantwortlicher möchte ich eine Produkttour durch die Workflow-Management-Lösung machen, damit ich besser verstehen kann, wie sie Mehrwert für meine Geschäftsprozesse schafft.

Laufende Betreuung.

Der Erfolg eures Produkts hängt von eurer Fähigkeit ab, Kundinnen und Kunden zu gewinnen und zu binden. Wenn ihr eine hohe Kundenbindungsrate erzielt und aufrechterhaltet, zeigt das, dass ihr eurem Kundenstamm Mehrwert bietet.

Eine bindungsbezogene User Story könnte folgendermaßen aussehen:

Als Inhaber eines E-Commerce-Unternehmens möchte ich eine Lösung, die skalierbar ist, damit ich das langfristige Wachstum meines Onlineshops fördern kann.

Erste Schritte mit User Storys.

User Storys sind hilfreich, um sich zu überlegen, wie Anwenderinnen und Anwender mit eurem Produkt interagieren. Wie diese Beispiele zeigen, lässt sich das User-Story-Framework an das von euch bevorzugte Medienformat anpassen.

Diese Mikronarrative können auf verschiedene Abschnitte eures Produktentwicklungszyklus und jede Phase der Customer Journey angewendet werden.

Wenn ihr bereit sind, diese Beispiele zu übernehmen, solltet ihr einige Konzepte für euer Produkt, euren Service oder euer Unternehmen festhalten. Um euren Prozess voranzubringen, könnt ihr diesen Artikel mit eurem Team teilen, um zu erörtern, wie User Storys euch die Arbeit erleichtern.

Erwägt außerdem, wie sich User Storys in euren aktuellen Workflow einfügen und ob Anpassungen erforderlich sind, um User Storys aufzugreifen und gewinnbringend einzubinden.

Adobe hat die passende Lösung.

Adobe Workfront ist eine effektive Work-Management-Software, die euer Team bei der Umsetzung seiner Agile-Ziele unterstützt. Workfront ist eine Work-Management-Lösung für Unternehmen, die Aufgaben mit Strategien verknüpft und die Zusammenarbeit unterstützt, um messbare Geschäftsergebnisse zu erzielen. Durch die Optimierung und Zentralisierung digitaler Projekte erhalten bereichsübergreifende Teams an jedem beliebigen Standort die Möglichkeit, sich auszutauschen, zusammenzuarbeiten und Pläne umzusetzen, sodass ihr Potenzial voll ausgeschöpft wird.

Wenn ihr mehr erfahren wollt, seht euch das Übersichtsvideo an oder startet eine Produkttour.