Was ist eine User Story? Wie (und warum) schreibt man eine?
Eine User Story ist ein zentrales Werkzeug bei Teams, die agil arbeiten. Ihr Einsatzgebiet ist sehr breit und reicht von der Befriedigung spezifischer Kundenbedürfnisse bis zur Unterstützung von agilen Projekten bzw. agilen Methoden der Scrum-Teams.
Aber was genau ist eine User Story und wie erstellt man eine? In diesem Artikel klären wir alles: Wir zeigen Ihnen, wie eine User Story erstellt und aufgebaut sein sollte und wie Sie erfolgreich mit diesem Tool arbeiten können.
Entdecken wir die User Stories zusammen
User Story: Definition
User Story ist ein englischer Begriff, der wörtlich mit "Benutzer Geschichte" übersetzt werden kann. Im Bereich des agilen Projektmanagements und der Softwareentwicklung ist die User Story eine Scrum-Technik, die es erlaubt, die Funktionalitäten eines gegebenen Systems aus der Sicht des Anwenders und der User Experience zu beschreiben.
Die User Story kommt ursprünglich aus der agilen Methode “Extreme Programming” (XP) und wird heutzutage hauptsächlich im Scrum-Framework benutzt.
Was ist die Funktion der User Story?
Die Funktion einer User Story ist es, die spezifischen Bedürfnisse und Erwartungen der Endbenutzer bezüglich einiger Funktionalitäten einer Software oder einer vorgeschlagenen Lösung zu erfüllen.
Die User Story hat nämlich den Zweck, dem Leser verständlich zu machen, worin der Nutzen des untersuchten Systems besteht. Auf diese Weise ist es möglich, einen höheren Bekanntheitsgrad der Vorteile des vorgestellten Produkts oder der Dienstleistung zu erreichen.
Eine User Story dient ja dazu, das Verständnis für ein System zu erhöhen und damit den Erfolg bei den Anwendern zu fördern.
Dieses kurze Video gibt Ihnen eine detaillierte und vereinfachte Beschreibung der User Story.
User Stories: warum sie verwenden?
Eine User Story ist ein praktisches und günstiges Tool in Bezug auf Kosten und Zeit. Mit den User Stories sind mehrere Vorteile verbunden, wie zum Beispiel:
- Eine User Story kann die iterative Entwicklung eines Systems unterstützen, besonders wenn sie detailliert genug ist;
- Sie ist leicht zu verstehen und wird sofort angenommen;
- Sie kann schnell erstellt, geändert und ersetzt werden.
Heutzutage sind User Stories eines der beliebtesten Werkzeuge des gesamten Team, um die Funktionalität eines Produktes oder einer Dienstleistung zu formulieren und zu diskutieren. Deshalb ist die Kenntnis ihrer Mechanismen und das Erlernen ihrer Beherrschung grundlegend für eine zielgerichtete Implementierung eines jeden entwickelnden Systems.
User Story vs. Use Case
Der Use Case kann als eine massivere Version der User Story betrachtet werden. Er ist vollständiger als eine User Story und enthält in der Regel verschiedene User Stories.
Der User Case ist normalerweise langlebiger als eine User Story. Der User Case wird in der Regel während der gesamten Entwicklung des Systems gepflegt, während die User Story nach ihrer Fertigstellung in dem entsprechenden Sprint verschwindet.
Eine User Story schreiben
Wer schreibt eine User Story?
User Stories können von den oder für die Endnutzer geschrieben werden.
Laut Scrum Guide kümmert sich der Product Owner um die Einträge in das Product Backlog: Er muss sie schön auflisten und priorisieren, damit die Arbeit in der richtigen Reihenfolge erfolgt. Das heißt aber nicht, dass er unbedingt die User Stories schreiben muss: Er kann diese Aufgabe delegieren.
Wie wird eine User Story geschrieben?
Normalerweise ist die User Story das Ergebnis eines Entwicklungsteams. Normalerweise konzentriert sich das Team zunächst auf die Entwicklung bestimmter Kriterien zu Ihrer Erstellung. Diese können z. B. der Grad der Komplexität, das zu befolgende Modell, die Einstellung der Informationen usw. sein.
Es müssen also von Anfang an die strukturellen Eigenschaften definiert werden, die Sie der User Story zuschreiben wollen. Wenn Sie in einem Team arbeiten, ist es sinnvoll, die Aufgaben innerhalb der Gruppe aufzuteilen und den Zeitrahmen festzulegen, in dem die Arbeit erledigt werden muss.
Zu Beginn müssen die Story Points festgelegt werden: Story Points sind willkürliche Zahlen sind, mit denen man abschätzen kann, wie viel Arbeit das Team in jeder Iteration erledigen kann.
Dann kann man eventuell auch Sprints festlegen: Es sind Arbeitszyklen, die zwischen einer und vier Wochen dauern. Die Menge der Story Points und Sprints bilden die Grundlage für das User Story Planning.
☝ In diesem Zusammenhang wurde von Sprints im Plural gesprochen. Beachten Sie jedoch, dass für die Erstellung einer User Story oft nur eine Iteration, also ein Sprint, benötigt wird.
Der nächste Schritt besteht darin, sicherzustellen, dass die Aufgaben klar formuliert sind und den Mitgliedern zugewiesen werden. Organisation und Koordination sind der Schlüssel zum Schreiben einer hochwertigen User Story.
Es kommt jedoch vor, dass User Stories ohne eine detaillierte Analyse der zu erledigenden Aufgaben geschrieben werden. Der Grad der Strukturierung der Story ist in der Tat ein willkürlicher Faktor und unterliegt der freien Wahl der Arbeitsgruppe. Es liegt auf der Hand: Je mehr ein Team exzellente Dienstleistungen garantieren will, desto mehr muss es eine artikulierte Planung der User Story durchführen.
☝ Die Planung der User Story muss den Nutzen des Anwenders zum Ziel haben, nicht die Promotion der jeweiligen Lösung, des Produkts oder der Dienstleistung.
Die nächsten Schritte
User Stories werden im Product Backlog verwaltet. Hier kommt das von Roman Pichler entwickelte DEEP-Konzept ins Spiel. Er hat dieses Modell entworfen, um einen korrekten Backlog zu betreiben. DEEP ist ein Akronym, das für die folgenden Wörter steht:
- Detailed Appropriately (angemessen detailliert): User Stories mit hoher Priorität sollten detaillierter formuliert werden als solche mit niedriger Priorität.
- Estimated (geschätzt): Die Komponenten der User Story sollten bewertet werden, insbesondere in Bezug auf die Story Points. Die Kenntnis der Elemente, aus denen eine Geschichte besteht, hilft dabei, Prioritäten zu setzen und das Release-Projekt zu verfolgen.
- Emergent: Die User Story hat einen dynamischen Charakter. Sie entwickelt sich ständig weiter, sowie ihr Inhalt. Neue Elemente können aufgrund von Leserbewertungen, Anforderung und Feedback hinzugefügt werden. Auf dieser Basis müssen die User Stories modifiziert, aktualisiert und optimiert werden.
- Prioritized (priorisiert): Story-Komponenten oder die Storys selbst mit hoher Priorität sollten zuerst implementiert werden.
Wie sollte man konkret eine User Story entwickeln?
Wenn Sie dabei sind, eine User Story zu schreiben, ist es gut, eine grundlegende empfohlene Struktur im Auge zu behalten:
Als x (Rolle des Verfassers) möchte ich xy (Hinweis auf die gewünschte Funktionalität), um yy (Zweck) zu erreichen.
Neben diesem Grundmodell gibt es weitere Alternativen. Ein anderes mögliches Modell für eine User Story ist zum Beispiel:
Um yy (Zweck) zu erreichen, da ich x (Rolle) bin, möchte ich xy (Funktionalität).
☝ Die Rolle muss auf Ihre Personas abgestimmt sein. Eine Persona ist ein typischer Vertreter Ihrer Zielgruppe.
User Stories können, wie alle anderen Stories auch, im Detailgrad variieren. Einige Stories können nur sehr grobe Inhalte liefern. Andere wiederum können einen generischen Anfang haben, der erst später verfeinert wird. Andere können von Anfang an detailliert sein.
Die Verwendung einer Vorlage zur Formulierung Ihrer User Story ist nicht zwingend erforderlich, aber praktisch. Erfahrungen im Bereich der User Stories haben gezeigt, dass die Einhaltung der empfohlenen Grundstruktur nicht nur die Formulierung der User Stories erleichtert, sondern auch die Verständlichkeit für den Leser erhöht.
In welcher Sprache soll eine User Story geschrieben werden?
Die bevorzugte Sprache für das Schreiben einer User Story ist Englisch. Es könnte komisch klingen, besonders wenn Sie auf dem deutschen Markt aktiv sind. Doch längst ist Englisch in fast allen Ländern zur Lingua franca geworden und wird auf internationaler Ebene gesprochen.
Darüber hinaus erlaubt diese Sprache ein hohes Maß an Prägnanz, da sie extrem synthetisch und direkt ist.
Aus diesem Grund kann es eine kluge Entscheidung sein, die User Story auf Englisch zu präsentieren.
User Story: Beispiele
Im Folgenden finden Sie einige Anwendungsbeispiele für die vorgeschlagenen User-Story-Modelle:
1. Als Liebhaber historischer Romane möchte ich gerne über die entsprechenden Neuerscheinungen informiert werden, um sie rechtzeitig im Buchhandel bestellen zu können.
2. Als Liebhaber von Abenteuerfilmen würde ich gerne wissen, welche Filme dieses Genres in Ihrem Kino gezeigt werden, um online Tickets kaufen zu können.
3. Um ein erschwingliches Abonnement zu finden, da ich ein Filmliebhaber bin, würde ich gerne Informationen über die in Ihrem Kino verfügbaren Angebote erhalten.
Excel-Vorlage kostenlos herunterladen
Möchten Sie eine qualitativ hochwertige User Story mit minimalem Aufwand erstellen? Laden Sie unsere kostenlose, gebrauchsfertige Excel-Vorlage herunter!
User Story
DownloadDas INVEST-Prinzip
Eine Möglichkeit, die Effektivität Ihrer User Story zu testen, ist die Anwendung des von William Wake formulierten Prinzips. INVEST ist auch ein Akronym und steht für:
- Independent: Die User Story besitzt eine eigene Individualität und ist unabhängig von anderen User Stories.
- Negotiable: Der Inhalt ist umsetzbar und kontinuierlich verbesserungsfähig. Er entwickelt sich aus einer Zusammenarbeit zwischen dem Leser und den Verfassern der Story. So kann es im Laufe seiner Realisierung und Erprobung immer mehr ins Detail gehen.
- Valuable: Die User Story muss für den Kunden wertvoll sein. Er muss dem Leser einen Vorteil oder Nutzen bieten und Hinweise geben, wie er diesen erreichen kann.
- Estimable: Die User Storys Abschätzbarkeit ist die Voraussetzung und die Conditio-sine-qua-non dafür, dass sie verhandelbar ist. Die Evaluierbarkeit des Aufwand einer User Story hängt auch von ihrer Größe ab: Je länger eine Story ist, desto schwieriger wird sie zu evaluieren sein. Darüber hinaus hängt dieses Kriterium auch von der Erfahrung des Teams ab: Eine Gruppe von Experten wird eine Geschichte mit mehr Geschick und Unmittelbarkeit bewerten können als Neulinge.
- Small: Qualitativ hochwertige User Stories neigen dazu, kurz zu sein. Übrigens: Je kürzer eine Geschichte ist, desto besser ist sie zu bewerten und das Ziel erreicht.
- Testable: User Story hat Akzeptanzkriterien und kann getestet werden. Wenn eine Geschichte kaum von Anwendern getestet werden kann, kann das bedeuten, dass sie nicht klar genug ist, oder dass sie dem Leser keinen wertvollen Nutzen bietet.
Letztlich dienen alle Punkte des INVEST-Prinzips dazu, die Qualität einer User Story zu bewerten und auch die Umsetzung so zu gestalten, dass sie effektiv ist. Das Einhalten der Punkte in diesem Modell kann den Erfolg Ihrer User Story entscheidend beeinflussen!
Die Hierarchie der User Stories
Wie das INVEST-Prinzip besagt, sollten die User Stories unabhängig voneinander sein. In der Praxis kommt es jedoch häufig vor, dass zwischen verschiedenen User Stories Abhängigkeiten bestehen. Die Abhängigkeit von User Stories kann unterschiedlicher Art sein. Sie kann z. B. auf der inhaltlichen, technischen, normativen, regulatorischen, zeitlichen usw. Ebene liegen.
Die Existenz von Abhängigkeiten zwischen User Stories ist oft nicht offensichtlich, deshalb ist es sinnvoll, ein User Story Mapping zu verwenden, um diese zu finden und zu beseitigen.
User vs. Epic Story
Innerhalb der Makro-Kategorie der User Stories gibt es eine grundlegende Unterscheidung. Je nach Ausmaß des Nutzens, den sie dem Leser bieten, können User Stories auch als Epic Stories bezeichnet werden.
Die Unterscheidung dieser beiden Kategorien ist nicht homogen und immer gleich. Das bedeutet, dass es keinen anerkannten Standard gibt, nach dem eine Geschichte automatisch als User oder Epic eingestuft wird.
Generell kann eine Epic Story aber als eine User Story definiert werden, die ein hohes Maß an technischer und fachlicher Bedeutung besitzt. Die Epic Stories beschreiben die Funktionalitäten in der Regel absolut detailliert, technisch und spezifisch.
Verstehen Sie alle Unterschiede mit diesem kurzen Video
Management-Tools: Akzeptanzkriterien
Man kann sicher sein, dass eine User Story vollständig implementiert wurde, wenn die Akzeptanzkriterien nachweislich erfüllt sind. Doch was sind Akzeptanzkriterien?
Akzeptanzkriterien in Bezug auf eine User Story sind die Parameter, die zeigen, dass die wesentlichen Ergebnisse der User Story erreicht wurden.
Die Parameter, auf die wir uns beziehen, sind die W-Fragen (Wer? Was? Warum? Wann? Wo? usw.).
Diese erlauben uns zu verstehen, ob eine User Story effektiv ist und alle möglichen kognitiven Bedürfnisse des Lesers anspricht.
Akzeptanzkriterien sind also Tests, die auf die User Story angewendet werden, um ihre Angemessenheit entsprechend dem Verwendungszweck zu überprüfen. Besonderes Augenmerk muss in diesem Zusammenhang auf die Identifizierung von Schlüsselwörtern gelegt werden, d.h. auf die Verwendung von relevanten Verben, Adjektiven und Substantiven.
Tipps für eine User Story höher Qualität
Da die User Story in kürzester Zeit empfangen und verstanden werden soll, ist es wichtig, dass sie:
- Ist in kurzen, prägnanten Sätzen geschrieben wird;
- Ein einfaches und unverfälschtes Vokabular verwendet;
- Technische Details vermeidet: Menschen ohne fachlichen Hintergrund müssen verstehen können, was sie lesen;
- Sie konzentriert sich darauf, direkte Antworten auf die Fragen zu geben: Wer will was von dem System? Warum nutzt der Anwender das System (für welchen Nutzen)?
Nach den Worten von Mike Cohn, einem der Hauptverantwortlichen für die Erfindung der Scrum Methode, bestehen alle agilen User Stories aus nur ein oder zwei einfach geschriebenen Sätzen und vor allem aus einer Reihe von entsprechend ausgelösten Gesprächen über die gewünschte Funktionalität.
User Story : Für eine nutzerzentrierte Entwicklung.
User Stories sind wertvolle Werkzeuge im Entwicklungsprozess, die es ermöglichen, die Bedürfnisse der Nutzer zu verstehen und auf effiziente und zielgerichtete Weise zu erfüllen. Sie fördern eine klare Kommunikation zwischen allen am Projekt beteiligten Mitgliedern.
Mit einem user-zentrierten Ansatz können Entwicklungsteams Produkte und Funktionen entwickeln, die wirklich den Erwartungen der Nutzer entsprechen, und so deren Zufriedenheit und den Erfolg Ihres Projekts fördern.