User Stories sind Teil des agilen Managements Bevor wir allerdings zu den User Stories kommen müssen wir ein paar grundlegende Fragen klären
Wer schreibt User Stories?
Der Product Owner ist der alleinige Entscheider über das Product Backlog. Somit trägt er auch die Verantwortung über Quantität und Qualität der User Stories. Das bedeutet jedoch nicht, dass der Product Owner sie auch schreibt. Jeder kann also User Stories schreiben. Im Laufe eines guten agilen Projekts sollten von jedem Teammitglied User-Stories geschrieben werden. Hier gilt es zu beachten, dass Teammitglieder, die sich aktiv an Diskussionen beteiligen wertvoller sind als diejenigen die eine User Story schreiben ohne Kontext zu liefern oder für allgemeines Verständnis zu sorgen.
User Stories aus verschiedenen Prespektiven schreiben – Personas
Eine hervorragende Methode, um deine Erkenntnisse über Benutzer und Kunden zu erfassen, ist die Arbeit mit Personas. Personas sind fiktive Charaktere, die auf der Kenntnis der Zielgruppe basieren. Sie bestehen in der Regel aus einem Namen und einem Bild, relevanten Merkmalen, Verhaltensweisen und Einstellungen. Das Ziel ist der Nutzen, den die Persona erreichen will, oder das Problem, das der Charakter mit dem Produkt lösen will. Die Personas helfen, die richtigen User Stories zu herauszufiltern.
Wann werden User Stories geschrieben?
User Stories werden während des gesamten agilen Projekts geschrieben. Ich empfehle, mindestens einen Workshop zum Schreiben von User Stories zu Beginn eines agilen Projekts abzuhalten. Jeder im Team beteiligt sich mit dem Ziel, ein gemeinsames Product Backlog zu schaffen. Darüber hinaus können jederzeit und von jedermann neue User Stories geschrieben und dem Produkt-Backlog hinzugefügt werden.
Starte mit einer Vision
Starte ein Projekt nicht mit User Stories, sondern beginne mit der Erstellung einer Vision. Bevor eigene User Stories erstellt werden können, muss das Team das große Gesamtbild verstehen. Es ist aufwendig aber lohnenswert, auf der höchsten Ebene festzustellen, was die hochwertigsten Funktionen sind, die an die Kunden geliefert werden sollen.
Mach weiter mit Epics
Einer der Vorteile von agilen User Stories ist, dass sie in unterschiedlichen Detaillierungsgraden geschrieben werden können. Wir können auch Benutzergeschichten schreiben, die große Mengen an Funktionalitäten abzudecken. Diese großen Benutzergeschichten sind allgemein als Epics bekannt. Ein Epic ist eine große, skizzenhafte, grobkörnige Geschichte. Es ist in der Regel in mehrere User Stories unterteilt, die das Feedback der Anwender zu frühen Prototypen und Produkterweiterungen nutzen. Man kann es sich daherals Überschrift und Platzhalter für detailliertere Geschichten vorstellen.
Mit Epics können Produktfunktionalitäten skizziert werden, ohne sich in Details zu verlieren. Dies ist besonders hilfreich bei der Beschreibung neuer Produkte und Funktionen. Somit kann ein grober Umfang erfasst werden. Zudem reduziert sich der Aufwand bei der Integration neuer Erkenntnisse. Viele detaillierte Geschichten im Produkt-Backlog haben zur Folge, dass sich Feedback oft als schwierig und zeitaufwendig gestaltet.
Schreibe User Stories
Alle agilen User Stories enthalten ein oder zwei geschriebene Sätze. Zweck einer User Story ist es, das Niederschreiben einer Anforderungen gegen Diskussionen über die gewünschte Funktionalität auszutauschen. Schreibt User Stories auf Karteikarten oder Post It’s und stellt sie sichtbar in eurem Teamraum dar. Sie folgen in der Regel einer einfachen Vorlage:
Als < Nutzer >, wünsche ich < Ziel > damit < Grund >.
Nutzer
Die Rolle beschreibt, wer von dieser Funktion profitieren wird. Beachten Sie, dass die Rolle nicht einfach nur „der Nutzer“ ist. Es gibt verschiedene Arten von Nutzern. Daher müssen diese beschrieben und von allen Teammitgliedern verstanden werden (s. Personas). Product Owner können sich nicht (immer) in die Köpfe ihrer Anwender hineindenken und sich dort zurechtzufinden.
Ziel
Dieser Schritt kurz und bündig, was sich der Nutzer wünscht. Dies entspricht am ehesten einer Anforderung, die man aus der traditionellen Softwareentwicklung kennt. Die Nutzergeschichte sollte aber immer aus der Perspektive des Nutzers geschrieben werden, der von der Funktion profitiert, nicht aus der Perspektive des Entwicklers, der sie programmieren wird.
Grund
Abschließend möchte man wissen, warum sich der Nutzer diese Funktion wünscht und welchen Wert er davon hat. Dies hilft dem Product Owner zu beurteilen, wie er die User Story auf dem Backlog priorisieren kann. Wenn der Wert oder Nutzen nicht artikuliert werden kann, könnte es sein, das das Feature nicht notwendig ist. Das Verständnis des Wertes hilft dem Entwicklungsteam oft dabei, innovative Wege zu finden, den Code zu implementieren.
Welche Anforderungen müssen User Stories erfüllen
INVEST ist ein Akronym, das dir hilft zu beurteilen, ob du eine qualitativ hochwertige User Story hast.
Independent
Die Story sollte von einem Team umgesetzt werden können und dabei unabhängig von anderen Teams oder externen Rahmenbedingungen sein.
Negotiable
Die Story ist nicht zu detailliert. Höchstwahrscheinlich wird es gemeinsame Routinen oder Bibliotheken geben, die es dem Entwicklungsteam ermöglichen über die genaue Umsetzung der Story zu verhandeln.
Valuable
Das Feature, welches aus der Story entwickelt wurde ist für den Nutzer wertvoll, liefert also einen klar messbaren Nutzen.
Estimable
Das Team muss genügend Fragen stellen und Details sammeln, um sicher zu gehen, dass Aufwand und Wert einer Story sicher eingeschätzt werden kann.
Small
Die Nutzergeschichte muss klein genug sein, um sie innerhalb eines Sprint abschließen zu können.
Testable
Es müssen klar definierte Akzeptanzkriterien vorhanden sein, auf deren Erfüllung man das Feature testen können muss.
Deine User Stories sind zu detailliert?
Oft werden Geschichten zu groß und können nicht mehr innerhalb eines Sprints abgeschlossen werden. Sobald sich das Team eingehend mit den User Stories beschäftigt, stellt es fest, dass es zu viele Unbekannte gibt oder dass die betreffenden Aufgaben mehr Zeit benötigen. Details können jedoch jederzeit zu den User Stories hinzugefügt werden.
Stories splitten
Werden so viele Details zu einer User Story hizugefügt, dass sie nicht mehr innerhalb eines Sprints umsetzbar ist, wird diese relativ große Story in mehrere, kleinere, agile User Stories aufgeteilt. Eine Nutzergeschichte muss am Ende des Sprints immer funktionierende Software liefern, die einen Mehrwert für den Benutzer darstellt. Schneide die Geschichte daher in „vertikale Scheiben“, anstatt eine Nutzergeschichte zu erstellen, die eine Funktion nur teilweise vervollständigt.
Product Backlog Refinement
Es gibt zwei kritische Aspekte von User Stories: sie „ready“ zu machen und sie „done“ zu bekommen. Im Product Backlog Refinement -Meeting stellt der Product Owner sicher, dass die Nutzergeschichten „Ready“ sind. Nun kann das Team sie umsetzen und sie zu „Done“ bringen. Einen tiefergehenden Blick in das Product Backlog Refinement findest du in unserem Artikel [link tbr]
Dein Team hat unzählige User Stories geschrieben, doch in welcher Reihenfolge werden diese nun abgearbeitet? Wie man den Aufwand einer User Story schätzt und warum dies nicht aussreicht um ein Product Backlog zu priorisieren liest du in unserem Artikel Planning poker vs. Value poker – User Stories richtig schätzen
Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick