Was ist eine User Story? Wie (und warum) man eine schreibt
User Stories sind ein zentrales Werkzeug in der Zusammenarbeit von agilen Teams. Ihr Einsatzgebiet ist sehr breit und reicht von der Befriedigung konkreter Kundenbedürfnisse bis zur Unterstützung von Scrum-Teams.
Doch was genau ist eine User Story und wie wird sie realisiert? In diesem Artikel beleuchten wir dieses Konzept: Wir zeigen Ihnen, wie eine User Story aufgebaut sein sollte und wie Sie erfolgreich mit diesem Werkzeug arbeiten.
Entdeckung der User Stories
Benutzergeschichte: Definition
UserStory ist ein englischer Begriff, der wörtlich mit "Benutzergeschichte" übersetzt werden kann. Im Bereich des agilen Projektmanagements und der Softwareentwicklung ist die User Story ein Werkzeug zur Beschreibung der Funktionalität eines bestimmten Systems aus der Perspektive der Benutzererfahrung.
Wofür wird sie verwendet?
Die Funktion der User Story besteht darin, spezifische Benutzerbedürfnisse und -erwartungen bezüglich bestimmter Funktionalitäten einer vorgeschlagenen Software oder Lösung zu erfüllen.
Der Zweck der User Story besteht darin, dem Leser den Nutzen des betrachteten Systems zu verdeutlichen. Auf diese Weise kann ein höheres Maß an Bewusstsein für den Nutzen des vorgestellten Produkts oder der Dienstleistung erreicht werden.
Eine User Story dient also letztlich dazu, das Verständnis für ein System zu erhöhen und damit dessen Erfolgsgrad bei den Nutzern zu steigern .
User Story vs. Anwendungsfall
Der Use Case oder Anwendungsfall kann als eine umfangreichere Version der User Story betrachtet werden. Er ist in der Tat sehr ausführlich und detailliert, deckt einen größeren Kontext ab und ist daher umfassender als eine User Story. In der Regel umfasst er sogar mehrere User Stories.
Der Anwendungsfall ist normalerweise langlebiger als eine User Story. Er wird in der Regel während der gesamten Entwicklung des Systems beibehalten, während die User Story nach ihrer Fertigstellung in einem Sprint verschwindet.
Schreiben einer User Story
Wer schreibt sie?
User Stories können von oder für Benutzer geschrieben werden.
Wie wird sie geschrieben?
Normalerweise wird die User Story von einem Team geschrieben, das sich mit der Erstellung und Optimierung der User Story beschäftigt. In der Regel konzentriert sich das Team zunächst darauf, bestimmte Kriterien zu entwickeln, um die herum die Story entwickelt werden soll. Das können zum Beispiel der Grad der Komplexität, das zu befolgende Modell , das Layout der Informationen und so weiter sein.
Von Anfang an müssen also die strukturellen Eigenschaften festgelegt werden, die man der Geschichte zuschreiben möchte. Wenn Sie in einem Team arbeiten, sollten Sie die Aufgaben innerhalb der Gruppe aufteilen und den Zeitrahmen festlegen, in dem die Arbeit erledigt werden soll.
Zunächst müssen also Story Points festgelegt werden, d. h. willkürliche Zahlen, mit denen man abschätzen kann, wie viel Arbeit das Team in jeder Iteration erledigen kann.
Dann müssen auch Sprints, d. h. Arbeitszyklen von einer bis vier Wochen Dauer, festgelegt werden. Der Satz von Story Points und Sprints bildet die Grundlage für das User Story Planning.
☝ In diesem Zusammenhang wird von Sprints im Plural gesprochen. Es ist jedoch zu beachten, dass oft nur eine Iteration oder ein Sprint für die Realisierung einer User Story notwendig ist.
Der nächste Schritt besteht darin, sicherzustellen, dass die Aufgaben klar formuliert und den verschiedenen Teammitgliedern zugewiesen werden. Organisation und Koordination sind in der Tat entscheidend, um eine qualitativ hochwertige User Story zu schreiben.
Es kommt jedoch vor, dass User Stories ohne eine detaillierte Analyse der Aufgaben geschrieben werden. Der Grad der Strukturierung der Story ist in der Tat ein willkürlicher Faktor und unterliegt der freien Entscheidung des Teams. Es liegt auf der Hand, dass ein Team, das exzellente Dienstleistungen gewährleisten will, eine gegliederte Planung der User Story bevorzugt.
Der Zweck der User-Story-Planung muss der Nutzen des Benutzers sein, nicht die Förderung der in Betracht gezogenen Lösung, des Produkts oder der Dienstleistung.
Wie gehen wir vor?
User Stories werden im Backlog verwaltet. Hier kommt das DEEP-Konzept ins Spiel, das von Roman Pichler entwickelt wurde. Er hat sich dieses Modell ausgedacht, um ein korrektes Backlog zu betreiben. DEEP ist ein Akronym, das für die folgenden Wörter steht:
- Detailed Appropriately: User Stories mit hoher Priorität sollten detaillierter formuliert werden als solche mit niedriger Priorität.
- Geschätzt : Die Komponenten der User Story sollten geschätzt werden, insbesondere in Bezug auf die Story Points. Die Kenntnis, wenn auch nur ungefähr, der Bestandteile einer Story hilft bei der Priorisierung und Verfolgung des Release-Projekts.
- Emergent : Die User Story hat einen dynamischen Charakter. Sie entwickelt sich weiter und ihr Inhalt kann sich häufig ändern. Neue Elemente können auf der Grundlage von Leserbewertungen und Feedback entstehen. Auf dieser Grundlage müssen die User Stories geändert, aktualisiert und optimiert werden.
- Priorisierung : Story-Komponenten oder Storys selbst mit hoher Priorität sollten zuerst umgesetzt werden.
Wie sollte man an eine User Story herangehen?
Wenn Sie dabei sind, eine User Story zu schreiben, ist es gut, eine grundlegende empfohlene Struktur im Kopf zu behalten:
Als x (Rolle des Autors) möchte ich xy (Verweis 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 Stories, in ihrem Detailgrad variieren. Einige Geschichten können nur einen sehr groben Inhalt haben. Andere wiederum können einen generischen Anfang darstellen, der später noch verfeinert wird. Wieder andere können von Anfang an sehr detailliert sein.
Die Verwendung einer Vorlage für die Formulierung der eigenen User Story ist nicht zwingend erforderlich, aber sinnvoll. Die Erfahrung im Bereich der User Stories hat gezeigt, dass die Einhaltung der empfohlenen Grundstruktur nicht nur die Formulierung erleichtert, sondern auch das Verständnis des Lesers fördert.
In welcher Sprache sollte geschrieben werden?
Die bevorzugte Sprache für das Verfassen einer User Story ist Englisch. Das mag seltsam klingen, vor allem wenn man in der italienischen Szene tätig ist. Aber Englisch ist längst zur Lingua franca in fast allen Ländern geworden und wird heute international gesprochen.
Außerdem erlaubt diese Sprache ein hohes Maß an Prägnanz, da sie sehr knapp und direkt ist.
Deshalb kann es sinnvoll sein, seine User Story auf Englisch zu präsentieren.
Beispiele für Benutzergeschichten
Nachfolgend finden Sie einige Beispiele für die Anwendung der vorgeschlagenen User-Story-Modelle.
1. Als Liebhaber historischer Romane möchte ich über das Erscheinen relevanter Bücher informiert werden, um sie rechtzeitig in der Buchhandlung bestellen zu können.
2. Als Liebhaberin von Abenteuerfilmen möchte ich wissen, welche Filme dieses Genres in Ihrem Kino laufen, um online Karten kaufen zu können.
3. Da ich ein Kinoliebhaber bin, möchte ich wissen, welche Sonderangebote es in Ihrem Kino gibt, damit ich ein günstiges Abonnement finden kann.
Tipps für eine gute User Story
Da die User Story in kürzester Zeit aufgenommen und verstanden werden soll, ist es wichtig, dass sie:
- In kurzen, prägnanten Sätzen geschrieben ist;
- einen einfachen, nicht recherchierten Wortschatz enthält;
- Fachausdrücke vermieden werden: Auch Menschen ohne Fachkenntnisse müssen verstehen können, was sie lesen;
- Konzentration auf direkte Antworten auf die Fragen: Wer will was von dem System? Warum nutzt der Benutzer das System (mit welchem Nutzen)?
Nach den Worten von Mike Cohn, einem der Hauptverantwortlichen für die Erfindung der Softwareentwicklungsmethodik Scrum, bestehen alle agilen Benutzergeschichten aus nur einem oder zwei einfach geschriebenen Sätzen und vor allem aus einer Reihe von Gesprächen, die entsprechend über die gewünschte Funktionalität geführt werden.
Management-Tools: Akzeptanzkriterien
Man kann sicher sein, dass eine Benutzergeschichte vollständig implementiert wurde, wenn die Akzeptanzkriterien nachweislich erfüllt sind. Aber was sind Akzeptanzkriterien?
Unter Akzeptanzkriterien in Bezug auf eine User Story verstehen wir die Definition der Parameter, die zeigen, dass die Schlüsselergebnisse der User Story erreicht wurden.
Die Parameter, auf die wir uns beziehen, sind die W-Fragen (Wer? Was? Warum? Wann? Wo? usw.).
Diese ermöglichen es zu verstehen, ob eine User Story effektiv ist und alle möglichen kognitiven Bedürfnisse des Lesers befriedigt.
Akzeptanzkriterien sind also Tests, die auf die User Story angewandt werden, um ihre Angemessenheit in Bezug auf den Verwendungszweck zu überprüfen. Besonderes Augenmerk muss in diesem Zusammenhang auf die Identifizierung und Anreicherung von Schlüsselwörtern gelegt werden, d.h. auf die Verwendung von relevanten Verben, Adjektiven und Substantiven.
Das INVEST-Prinzip
Eine Möglichkeit, die Wirksamkeit Ihrer User Story zu testen, ist das von William Wake formulierte Prinzip. INVEST ist ebenfalls ein Akronym und steht für:
- Unabhängig: Die User Story hat ihre eigene Individualität und ist unabhängig von anderen User Stories.
- Negotiable: Der Inhalt ist umsetzbar und kontinuierlich verbesserungsfähig. Sie wird durch eine Zusammenarbeit zwischen dem Leser und den Machern der Story entwickelt. Sie kann also im Laufe der Realisierung und des Testens weiter ins Detail gehen.
- Wertvoll: Die User Story muss für den Kunden von Wert sein. Sie muss dem Leser einen Vorteil oder Nutzen bieten und Hinweise geben, wie er diesen erreichen kann.
- Abschätzbar: Die Bewertbarkeit einer User Story ist die Voraussetzung und Bedingung dafür, dass sie verhandelbar ist. Die Bewertbarkeit einer User Story hängt auch von ihrem Umfang ab: Je länger eine Story ist, desto schwieriger ist sie zu bewerten. Darüber hinaus hängt dieses Kriterium auch von der Erfahrung des Teams ab: Eine Gruppe von Experten wird eine Story mit mehr Geschick und Unmittelbarkeit bewerten können als Neulinge.
- Klein: Qualitativ hochwertige User Stories sind in der Regel kurz. Übrigens, je kürzer eine Story ist, desto besser ist sie evaluierbar.
- Testbar: Die Benutzergeschichte hat Akzeptanzkriterien und kann getestet werden. Wenn eine Story von den Nutzern kaum 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 beurteilen und auch ihre Umsetzung so zu steuern, dass sie effektiv ist. Die Befolgung der in diesem Modell vorgeschlagenen Punkte kann für den Erfolg Ihrer User Story den entscheidenden Unterschied ausmachen!
Die User-Story-Hierarchie
Wie das INVEST-Prinzip verdeutlicht, sollten User Stories unabhängig voneinander sein. In der Praxis ist es jedoch oft so, dass zwischen verschiedenen User Stories Abhängigkeiten bestehen. Die Abhängigkeit von User Stories kann unterschiedlicher Art sein. Sie kann z.B. auf inhaltlicher, technischer, normativer oder regulatorischer, zeitlicher Ebene usw. liegen.
Das Vorhandensein von Abhängigkeiten zwischen User Stories ist oft nicht offensichtlich, weshalb es sinnvoll ist, User Story Mapping zu verwenden, um sie aufzudecken und zu beseitigen.
User vs. Epic Stories
Innerhalb der Makrokategorie der User Stories gibt es eine grundlegende Unterscheidung. Je nach dem Umfang des Nutzens, den sie dem Leser bieten, können User Stories auch als Epic Stories bezeichnet werden.
Die Unterscheidung dieser beiden Kategorien ist nicht einheitlich und immer gleich. Das bedeutet, dass es keinen anerkannten Standard gibt, nach dem eine Story automatisch als User oder Epic eingestuft wird.
Generell kann eine Epic Story jedoch als eine User Story definiert werden, die ein hohes Maß an technischer und fachlicher Brisanz besitzt. Epic Stories beschreiben nämlich in der Regel die Funktionalität in einer absolut detaillierten, technischen und spezifischen Weise.
User Stories: warum sie verwenden?
Eine User Story ist ein praktisches und kostengünstiges Instrument, was die Kosten und die Zeit angeht, die man dafür aufwenden muss. Es gibt jedoch mehrere Vorteile, die mit ihr verbunden sind, wie z. B.:
- Besonders wenn sie detailliert ist, kann eine User Story die iterative Entwicklung eines Systems unterstützen;
- Sie ist leicht zu verstehen und wird sofort verstanden;
- Sie kann schnell erstellt, geändert und ersetzt werden.
Heutzutage sind User Stories eines der beliebtesten Werkzeuge, um die Funktionalität eines Produkts oder einer Dienstleistung zu formulieren und zu diskutieren. Deshalb ist es für eine zielgerichtete Implementierung eines jeden Systems entscheidend, ihre Mechanismen zu kennen und sie zu beherrschen.
Artikel übersetzt aus dem Italienischen