Die Nutzung von User Stories ist sehr weit verbreitet im Scrum-Alltag. Sie sind ein Werkzeug, das als selbstverständlich angesehen wird. Da lohnt es sich, etwas genauer hinzusehen.
Starten wir direkt: Der Scrum Guide kennt die User Story nicht. Im Abschnitt über das Product Backlog findet sich lediglich der abstrakte Begriff der "Product Backlog Items":
The Product Backlog is an emergent, ordered list of what is needed to improve the product. [...] Product Backlog items that can be Done by the Scrum Team [...]
Auch im Abschnitt über das Sprint Backlog findet sich nur eine unkonkrete Beschreibung:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
Die Nutzung der User Story ist somit ein möglicher Weg, ein Product Backlog Item zu konkretisieren.
Doch zunächst ein kurzer Blick auf die Historie.
User Stories haben ihren Ursprung in Extreme Programming (XP). XP selbst entstand im Umfeld von Chryslers Comprehensive Compensation System.
Eine später entstandene Quelle erwähnt etwas schwammig:
In Extreme Programming Installed, we describe the four elements of the XP “Circle of Life”: the on-site customer, working with the programmers, uses the planning game to select user stories to make up the most valuable small releases. Critical to this cycle are the user stories.
Das ist alles nicht sehr greifbar. Deshalb nun zur Erklärung des Sinns einer User Story.
Wie bei Story Points ist ein Problem, dass es keine einheitliche Definition einer User Story gibt. Eine gute Annäherung liefern diese beiden Erklärungen:
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
A User Story is a piece of system functionality, understood by the Customer / Product Owner, representing an increment of business value, to be implemented by the team.
Eine Option zur konkreten Ausformulierung folgt dem sog. "Connextra-Muster" (benannt nach der Firma, bei der es zum ersten Mal auftauchte):
Beispielhafte Ausformulierungen können z. B. sein:
Und das sind im Grunde bereits vollständige User Stories. Denn wie Alistair Cockburn so einprägsam formuliert hat:
A user story is a promise for a conversation.
Dies spiegelt sich wider im 3-C-Modell, welches drei einfache Eckpunkte festlegt:
Um dem CCC-Muster zu folgen, braucht es ein erfahrenes Team und eine reife Organisation, da es dem Team viel Freiraum lässt und einen Schwerpunkt auf Entdeckung legt. Wenn mehr Halt bzw. ein anderer Rahmen nötig ist, kann eine Definiton of Ready helfen.
Was bringen User Stories einem Scrum Team?
Im Kern sind User Stories das manifestierte Agile Manifesto 😁
Im Scrum-Alltag gibt es bei der Hebung der Vorteile jedoch einige Stolpersteine.
Aus persönlicher Erfahrung kenne ich v. a. zwei problematische Punkte bei der Nutzung von User Stories:
Der erste Punkt ist dabei am einfachsten zu adressieren: Nicht alles im Product Backlog oder Sprint Backlog muss eine User Story sein. Scrum spricht nur von allgemeinen Product Backlog Items und Stories sind eine mögliche Ausprägung eines Items. Passt ein einfacher "Task", ein "Bug"-Item oder ein anderes Format besser, dann spricht absolut nichts gegen eine Nutzung.
Auch braucht es keine "technischen User Stories" der Art "Als Entwickler brauche ich Zugriff auf eine Datenbank, um Kundendaten speichern zu können". Insofern das Produkt nicht zufälligerweise tatsächlich auf Entwickler als Endanwender ausgelegt ist, braucht es eine solche Story-Verrenkung nicht. Sinnvoller sein kann hier:
Der zweite eingangs erwähnte problematische Aspekt betrifft den Umfang bzw. Detaillierungsgrad einer User Story. Um es gleich zu sagen: Eine User Story ist keine Use Case-Beschreibung. Beide beschreiben eine Anforderung. Ein Use Case jedoch beschreibt dabei ausführlich, wie eine Anforderung behandelt wird. Eine Story hält einfach nur die Anforderung an sich fest.
Diesen feinen Unterschied zu vermitteln ist besonders schwer in Teams und Organisationen, die historisch geprägt sind von Projekten und klassischem Requirements Engineering. Es ist eine Illusion, selbst einfache Sachverhalte exakt und vollumfänglich aufschreiben zu können und diese Informationen ohne Verlust zwischen mehreren Köpfen zu transferieren. An dieser Stelle verweise ich dabei gerne auf die Exact Instructions Challenge.
Wichtig zu verstehen ist, dass die Arbeit mit Stories einen stark explorativen und kollaborativen Charakter hat. Ziel ist nicht, ein kleines Lastenheft zu schreiben, welches einfach von den Devs Punkt für Punkt umgesetzt werden muss. Eine User Story soll wiedergeben, was eine Nutzerin erreichen will und nicht, wie der exakte Weg dahin aussieht.
Genau deshalb sagt eines der agilen Prinzipien auch: Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Product Backlog Items sind, was am besten für ein Team funktioniert. User Stories haben sich als eine gute und beliebte Form herauskristallisiert. Dabei muss nicht alles im Backlog zwangsweise eine Story sein und nicht jede Aufgabe muss in das Story-Format gepresst werden.
Auch sind weder Product Backlog ein Lastenheft im Großen noch eine Story eines im Kleinen. Eine User Story ist ein lebendes Dokument zur Verfolgung eines zu erwartenden Nutzens einer Endanwenderin.
Das Erkennen der Unterschiede zwischen einem "was" und dem "wie" ist der schmale Grat zwischen zeitgemäßer und nachhaltiger Produktentwicklung und einer klassischen Projektmanagement-Denkweise.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.