Für mehr Story in der User Story

Als ich das erste Mal eine User Story schreiben sollte, war ich äußerst entsetzt: Ich als Nutzer wünsche mir einen Warenkorb, um mir einen Überblick über meine Bestellung verschaffen zu können.

Was soll das denn bitte für eine Geschichte sein? Und warum klingt jede Geschichte gleich?

Ich als <JEMAND> möchte <IRGENDWAS> tun, um ein <ZIEL> zu erreichen.

Und wieso muss ich überhaupt noch „literarisch“ tätig werden, wenn ich danach noch eine Liste mit Akzeptanzkriterien schreiben muss?

• [AK01] Der Warenkorb ist während des Einkaufsprozesses immer mit einem Klick erreichbar
• [AK02] Im Warenkorb werden alle Items mit Titel, Bild und Beschreibung gelistet
• [AK03] Es ist möglich, Artikel wieder zu entfernen und die Quantität zu ändern
• [AK04] Ein User kann wählen, ob sie oder er den Einkauf fortsetzen oder den Bezahlvorgang einleiten möchte

Da fragt man sich doch zurecht, weshalb es noch die vorangestellte schlechte Entschuldigung einer Story (also Geschichte) braucht.

Eine verpasste Chance

Meiner Meinung nach gibt es gute Gründe dafür, echte Storyies in Backlog Items zu schreiben: User Experience (UX), Customer Centricity und nicht zuletzt Motivation.

Gleiches Beispiel wie oben: Offensichtlich soll ein Einkaufswagen für eine Shopping-Webseite gebaut werden. Die Akzeptanzkriterien können wir also behalten. Technisch ist es genau das gleiche Ding, was am Ende des nächsten Inkrements Produktwert generieren soll.

Aber wie wäre es mit folgender einleitenden Story:

Petra hat innerhalb der letzten halben Stunde mehrere interessante Produkte in unserem Shop gefunden. Wie sie es von anderen Onlineshops gewohnt ist, würde sie diese gerne irgendwie sammeln, nochmal anschauen und am Ende (hoffentlich) bestellen.

Wir wollen ihr zu diesem Zweck – kreativ wie wir sind – einen digitalen Warenkorb zur Verfügung stellen.

Klar, die Story ist länger, weniger prägnant, gespickt mit überflüssigen Informationen und wirkt durch den informelleren Sprachgebrauch unprofessioneller. Aber sie kommt der Realität wesentlich näher als der Text einer klassischen User Story. Die neue Story hat eine Vorgeschichte, einen Hauptteil und ein offenes Ende. Aus der Geschichte geht jetzt sogar hervor, was der Geschäftsnutzen ist, der durch die Umsetzung entsteht: Der Bestellprozess wird verbessert.

Und wie eigentlich jede echte Geschichte hat unsere User Story nun sogar eine Protagonistin.

User Stories und Personas: Geschichten brauchen Hauptfiguren

Und diese Protagonistin muss der Product Owner sich im Idealfall nicht einmal selbst ausdenken. Wenn UX-Expertinnen und -Experten beteiligt waren, dann existieren vermutlich auch Personas für die potenzielle Nutzergruppe in den Projektunterlagen. Warum also nicht gleich die Charaktere aus den mühsam erstellten Personas als Heldinnen und Helden in die User Stories einbauen?

So eine Integration von Personas und User Stories hilft zusätzlich dabei, die verschiedenen Nutzertypen im Team bekannt zu machen. Ein Team, das eine gemeinsame Idee vom technikscheuen Timo (29) oder der ungeduldigen Ulla (19) hat, kann effizienter Software für solche Personengruppen entwickeln.

Ein weiterer Vorteil ist, dass das Dev-Team dann nicht per Diktat zum Personasbenutzen gezwungen wird – nach dem Motto „Denkt bitte an die Personas, wenn ihr Frontend-Umsetzungen macht!“. Stattdessen lernen alle Beteiligten ganz automatisch und nebenbei die verschiedenen Gruppen von Usern kennen.

Kollaboration statt blind AKs abarbeiten

Items im Product Backlog sollten keine 100 Prozent präzisen, starren, bindenden Verträge oder Anforderungskataloge sein. Sie sind vielmehr lebendige Arbeitsdokumente, die im Idealfall mit dem Produkt und/oder Projekt reifen. Oder wie das Agile Manifest sagen würde:

Individuals and interactions over processes and tools und Customer collaboration over contract negotiation.

Klassische User Stories bieten aus meiner Sicht dem Team zu wenig Anlass, sich kreativ einzubringen. Ganz im Gegenteil, Sie verleiten Product Owner dazu, überperfekte Backlog Items in die Entwicklung zu geben, die beim Team jegliche Motivation zum eigenständigen Denken im Keim ersticken.

Mit einer echten Geschichte hingegen kann sich jedes Teammitglied identifizieren – unabhängig von der Position oder vom technischen (oder nicht so technischen) Hintergrund. Über eine Geschichte kann man sich austauschen, denn sie ist persönlich, weckt Emotionen und befeuert die Kreativität. Menschen sind Geschichtenerzähler, warum also nicht diesen Fakt nutzen und Aufgaben in einer natürlichen, motivierenden und eventuell sogar spaßigen Weise aufbereiten.

Aber ist das auch INVEST-konform?

Der SCRUM-Kennende kennt INVEST als Bewertungsmaßstab für User Stories/Backlog Items. Oft sind die INVEST-Kriterien sogar in der „Definition of Ready (DoR)“ verankert:

• Independent (unabhängig)
• Negotiable (verhandelbar)
• Valuable (nützlich)
• Estimatable (schätzbar)
• Small (kleiner Umfang)
• Testable (testbar)

Einzeln betrachtet sehe ich keinen Grund, warum echte Geschichten in User Stories dazu führen sollten, dass ihre INVEST-Konformität verletzt würde:

• Independent bleibt unberührt, wir ändern ja nur die Form.
• Negotiable wird sogar verbessert, denn es gibt jetzt tatsächlich etwas, worüber man sich unterhalten kann.
• Valuable ist ähnlich wie Independent nicht weiter von der schöneren Geschichte betroffen.
• Estimatable ist mindestens so gut erfüllt wie bisher, wenn nicht sogar besser – immerhin kann man durch das detailliertere Bild, was man vom User gewonnen hat, möglicherweise genauer einschätzen, ob beziehungsweise welche Qualitätsanforderungen zu erfüllen sind.
• Small bezieht sich auf den Umfang der Anforderung und die Dauer der Implementierung. Die User Story an sich wird natürlich etwas länger.
• Testable ist ebenfalls genauso erfüllt wie bei einer klassischen User Story, denn die Akzeptanzkriterien sind gleich geblieben.

Fazit

Selbstverständlich müssen die Rahmenbedingungen stimmen, um so eine eher ausgefallene Methode zu testen. Sollte im Projekt mit Agilität ohnehin nicht viel los sein, ist es sicher empfehlenswert, mit etablierten Best Practices in die wunderbare Welt der agilen Softwareentwicklung zu starten.

Ein eingespieltes agiles Team aber kann eigentlich nur gewinnen, wenn es sich gemeinsam bei den User Stories mehr Freiraum zugesteht. Ich werde das auf jeden Fall ausprobieren, sobald sich die Gelegenheit bietet. Der Erfahrungsbericht folgt.