Der Product Owner und die Userstory

In diesem Beitrag beschäftigen wir uns mit den User Stories. Dabei werden wir zuerst deren Aufbau kennenlernen und erklären was Akzeptanzkriterien sind. Danach befassen wir uns mit den verschiedenen Klassen von User Stories. Wir werden uns anschauen, wie man User Stories am besten schreibt und sie bestmöglich schneidet. Auf Themen wie die drei Cs, die INVEST-Regel, die Definition of Ready und die Definition of Done werden wir ebenfalls eingehen.

Produkt- und Kundenanforderungen werden bei Scrum mittels User Stories abgebildet. Dabei liegt die Besonderheit darin, dass innerhalb einer User Story nur das, was erwartet wird, geschrieben steht und nicht die Art und Weise der Umsetzung. Sprich: das Ziel wird formuliert, nicht der Weg dahin.

Ein Beispiel-Template für eine User Story könnte zum Beispiel so aussehen, wie im Bild anbei.

Grundsätzlich erhält eine User Story einen Titel und eine Nummer. In gängigen Sprint-Tools setzt sich diese Nummer meist aus dem Projektkürzel und einer fortlaufenden Kartennummer zusammen.

Der Autor und das Einstelldatum sind ebenfalls Angaben, die ihre Wichtigkeit an einer User Story haben. So ist es mit dem Autor nützlich zu wissen, wen man bei Rückfragen zur User Story kontaktieren kann. Das Datum kann dem Product Owner später bei der Einschätzung helfen, ob die Priorität dieser Anforderung überdacht werden sollte. Liegt die Karte bekanntlich schon seit einem Jahr oder länger im Backlog, kann darüber diskutiert werden, ob sie überhaupt noch umgesetzt werden sollte.

Des Weiteren stehen an einer User Story deren Priorität sowie die vom Entwicklerteam im Refinement geschätzten Story Points. Diese sind später für die Sprintplanung wichtig.

Geschrieben wird die User Story aus Sicht einer bestimmten Persona, für die die Anforderung wichtig ist. Personas haben wir bereits kennengelernt als es um die Produktvision ging. Ziel ist es, die Lösung des Problems oder des Wunschs dieser Person so zu formulieren, das deutlich wird, welchen Nutzen sie durch die Umsetzung hat. Dabei verwendet man eine Struktur, die folgendermassen ausschaut:

Als <eine bestimmte Persona> möchte ich <meinen Wunsch erfüllt oder mein Problem gelöst haben> um <den folgenden Nutzen daraus zu ziehen>.

Dabei werden die Rolle, die Funktion und der Nutzen konkret aber einfach formuliert.

Ein Beispiel für eine User Story könnte also lauten:

• Als Kinobesucher möchte ich mir auf der Kinowebsite einen Platz für meinen Wunschfilm reservieren können, um nicht mit einer ausverkauften Vorstellung vor Ort überrascht zu werden.

Um eine auf die Persona zugeschnittene User Story bestmöglich zu schreiben, ist es wichtig mit anderen gemeinsam die Story zu besprechen. Sowohl mit der Zielgruppe, die die Persona verkörpert, als auch mit den Stakeholdern und den Entwicklern. Jeder sollte hinterfragen und Ideen einbringen können. Ein gemeinsames Verständnis wird somit optimal gefördert.

Als Grundlage dafür dienen die von Ron Jeffries formulierten drei Cs. Diese stehen für Card, Conversation und Confirmation. Die Karte steht hierbei für die formulierte User Story. Im Gespräch soll diese dann mit Stakeholdern und Kunden diskutiert werden. Damit wird sichergestellt, dass sowohl der Anforderungsumfang als auch die Priorität bestmöglich eingeschätzt werden kann. Als Bestätigung werden Akzeptanzkriterien formuliert. Diese konkretisieren die Anforderungen und sind verbindlich – das Inkrement muss jedes einzelne Akzeptanzkriterium einer User Story erfüllen, damit es abgenommen wird.

Beispielakzeptanzkriterien für unsere User Story könnten zum Beispiel lauten:

• Je Kinofilm auf der Webseite gibt es einen Button “reservieren”
• Mit Klick auf den Button “reservieren” gelangt man zu einem Reservierungs-Formular.
• Wenn der Film bereits ausverkauft ist, erscheint an der Stelle des Buttons “reservieren” eine Information, dass keine Karten mehr gekauft werden können.

Auf Grundlage dieser Erwartungshaltungen werden im Anschluss Tests erstellt, die dann die Akzeptanzkriterien überprüfen und die Umsetzung auf Korrektheit validieren. Die Akzeptanzkriterien sollten so geschrieben sein, dass man sie beim Test mit ja oder nein beantworten kann.

Die Vorteile von Akzeptanzkriterien liegen auf der Hand:

• Sie sparen Zeit, da durch die klare Beschreibung später keine Fragen oder Diskussionen aufkommen. Dies wiederum wirkt sich auch auf eine zügigere Schätzung aus.
• Sie fördern das Verständnis für die Anforderung und deren Erwartungen. Das Ergebnis ist konkret formuliert.
• Durch sie weiß man genau, wann die Erwartungen eines Product Backlog Item erfüllt sind.
• Durch sie bekommt man einen Input für die Testszenarien.

Wichtig ist, dass innerhalb der Akzeptanzkriterien nicht steht, wie etwas umgesetzt werden soll, sondern nur was am Ende zu sehen ist. Der technische Aspekt sollte herausgehalten werden. Das ist Sache des Entwicklungsteams.

Wenn wir das Product Backlog Item nun fertig beschrieben haben und die Definition of Ready erfüllt ist, kann es an die Umsetzung gehen. Die Definition of Ready ist in dem Fall eine Art Checkliste, die definiert, wann ein Product Backlog Item bereit für den Sprint ist. Erstellt wird diese Liste vom Product Owner und dem Entwicklungsteam. Darauf könnte zum Beispiel stehen:

• Akzeptanzkriterien sind vorhanden und werden vom ganzen Team verstanden.

oder

• Die User Story ist geschätzt.

Um eine eigene Definition of Ready zu erstellen, können die INVEST-Kriterien von Bill Wake helfen. Das Akronym INVEST steht hierbei für folgende Begriffe:

• Independent – unabhängig
• negotiable – verhandelbar
• valuable – wertvoll
• estimated – schätzbar
• small – klein genug
• testable – testbar

Schauen wir uns einmal jedes einzelne Kriterium genauer an:

I ➔ Independent – bedeutet, dass User Stories untereinander unabhängig sein sollen. Das ist wichtig, damit der Product Owner bei der Priorisierung der Items nicht jedes Mal darauf achten muss, ob eine andere vielleicht sogar niedriger priorisierte Anforderung der höher priorisierten vorzuziehen ist.

N ➔ Negotiable, also verhandelbar, soll eine User Story ebenfalls sein. Diskussionen und Gespräche mit dem Team sollen gefördert werden, so dass die für den Kunden optimalste Lösung dabei herausspringt.

V ➔ Valuable besagt, dass jede User Story einen Wert im Bezug auf den Business Value haben soll. Wichtig ist, die User Story dahingehend aktuell zu bewerten und nicht eine womöglich veraltete Story, die nun keinen Wert mehr hat, zu priorisieren.

E ➔ Estimated – die Anforderungen, die in User Stories formuliert werden, müssen schätzbar sein. Das bedeutet, dass die Entwickler den Aufwand für die Umsetzung abschätzen können, alle Informationen zu der Anforderung also vorliegen.

S ➔ Small bedeutet klein genug. Eine User Story sollte also innerhalb eines Sprints komplett abgearbeitet werden können. Das ist wichtig, da am Ende eines Sprints ein testbares, fertiges Inkrement steht. Falls innerhalb eines Refinements klar wird, dass eine User Story zu groß für einen Sprint ist, so muss der Product Owner diese weiter zerlegen und sinnvoll schneiden.

T ➔ Testable – Testbar muss die User Story sein. Das heißt, ein fertiges Inkrement ist am Ende des Sprints entstanden. Die Akzeptanzkriterien geben dann bestimmte Testcases, anhand dessen die Umsetzung geprüft werden kann.

Wenn man damit einmal seine eigene Definition of Ready erstellt hat, sollte man diese in regelmäßigen Abständen überprüfen und gegebenenfalls überarbeiten.

Nun ist es so, dass manche Backlog Items sehr groß sind und weiter geteilt werden sollten und andere wiederum nur einen kleinen Umfang haben. Damit kommen wir zu den verschiedenen Klassen der User Stories. Von der ursprünglichen Produkt Vision aus werden normalerweise Epics abgeleitet, um den Produktumfang erst einmal komplett zu skizzieren. Epics sind große Blöcke an Anforderungen, die noch nicht detailliert beschrieben sind. Man könnte sagen, es ist nur die Benennung eines größeren Themas.

In unserem Kinobeispiel könnte das zum Beispiel ein Epic mit dem Titel “Aufbau einer Kinoprogramm-Datenbank“ sein.

Erst, wenn das Epic laut Priorisierung an der Reihe ist, wird es weiter heruntergebrochen und die Details ausgearbeitet. Der Grund, warum diese umfangreichen Anforderungen erst dann genauer beschrieben werden, liegt darin, dass dies dem Sinn von Agilität entspricht. Kundenanforderungen können sich mit der Zeit ändern, aufbauend auf dem, was zum aktuellen Zeitpunkt umgesetzt wurde. Um nicht unnötig Zeit in Ausformulierungen zu investieren, geschieht dies erst dann, wenn die Umsetzung naht.

Aus Epics entstehen User Storys. Den Aufbau einer User Story haben wir schon geklärt.

Aus unserem Kino-Epic könnten dann folgende Beispiel User Stories entstehen:

• Als Kinobesucher möchte ich von zu Hause einen Überblick über alle aktuellen Filmen erhalten, um zu wissen, ob derzeit ein für mich interessanter Film im Kino läuft.
• Als Kinobesucher möchte ich meine Suche nach einem Film gern über bestimmte Filter einschränken, um nicht alle Filme des kompletten Kinoprogrammes durchsuchen zu müssen und somit Zeit zu sparen.
• Als Kinobetreiber möchte ich einen täglichen Import aller aktuellen und zukünftigen Filme in mein Kinoprogramm umgesetzt haben, um durch den Wegfall des händischen Einpflegens Zeit zu sparen.

Für eine genauere Aufgabenteilung einer User Story mit all ihren Akzeptanzkriterien erstellt das Scrum Team, hauptsächlich die Developer, während des Sprint Plannings Tasks oder Sub-Tasks. Das sind einzelne Aufgaben, die für die Umsetzung einer User Story notwendig sind und für die detaillierte Abarbeitung innerhalb des Sprints genutzt werden.

Tasks für die User Story, der die Suchfilter behandelt, können zum Beispiel sein:

• Suchformular anlegen sowie
• Daten aus Datenbank lesen und aufbereiten

Tasks können aber auch ohne Bezug zu einer User Story erstellt werden. Diese umfassen dann Aufgaben wie das Einrichten einer Entwicklungsumgebung oder einer Datenbank.

User Storys können sich sowohl im Product Backlog als auch im Sprint Backlog befinden. Epics hingegen verbleiben im Product Backlog und Tasks existieren nur im Sprint Backlog.

User Stories schneiden

Prinzipiell sollen User Stories soweit geschnitten sein, dass sie problemlos in einen Sprint passen. Das stellt einen Product Owner manchmal vor eine Herausforderung, wenn ansonsten alle INVEST Kriterien erfüllt sind, nur das Small passt nicht. Die Lösung ist dann, die User Story so zu schneiden, dass die entstehenden Einzelteile jeweils in einen Sprint passen und dabei die INVEST Kriterien weiterhin erfüllen.

Es ist sehr nützlich, sich als Product Owner dabei Hilfe von den Umsetzern bzw. den Developern zu holen, denn dem PO fehlt oft der technische Hintergrund, um die User Story sinnvoll zu teilen, da er normalerweise nicht alle Abhängigkeiten kennt.

Wie geht man hier nun am besten vor? Mike Cohn, der Mitgründer der Scrum Alliance, hat dazu fünf Techniken unter dem Akronym SPIDR zusammengefasst, die Denkanstöße liefern sollen, wie man am besten eine User Story teilen kann. Die einzelnen Buchstaben stehen in dem Fall für: Spikes, Paths, Interfaces, Data und Rules.

Spike bedeutet, dass man durch eine Recherche Wissen erlangen soll, um die Komplexität der zu großen User Story zu begreifen. Dabei soll man einen Prototypen erstellen, anhand dessen man die Anforderung besser versteht und diese dann somit auch besser teilen kann. Dass diese Technik am Anfang des Akronyms steht, ist nur dessen geschuldet, dass man es so besser aussprechen kann. Eigentlich sollte diese Methode nur angewendet werden, wenn die anderen vier Techniken nicht zum Erfolg beim Splitten helfen konnten.

Das Splitten anhand von Pfaden kann verschieden interpretiert werden. Zum einen stellt es die Möglichkeit vor, dass User Storys anhand der Alternativen gesplittet werden können. Stellen wir uns vor in unserem Kinobeispiel können sich die Besucher einloggen um Plätze für einen Kinofilm zu reservieren. Zum einen kann er sich ganz normal mit einem Nutzernamen und einem Passwort einloggen, zum anderen gibt es aber auch die Möglichkeit dies über Google oder Facebook zu machen. Wenn die Userstory mit dem Titel “Login” zu groß ist, könnte somit jede Alternative in eine eigene, kleinere Userstory gepackt werden.

Den Pfad kann man aber auch so verstehen, dass verschiedene Schritte der Anforderung nacheinander gesplittet werden können. Im Kinobeispiel und unserer Login User Story beschreibt ein Akzeptanzkriterium die Möglichkeit, bei vergessenen Zugangsdaten ein neues Passwort anfordern zu können. Genau diesen Workflow könnte man prima in eine eigene User Story auslagern.

Falls die Umsetzung aufgrund mehrerer Schnittstellen innerhalb einer User Story zu mächtig werden würde, kann es gut möglich sein, diese in einzelne Items aufzuteilen. Die verschiedenen Schnittstellen können in dem Fall eine Anbindung an verschiedene Systeme sein, oder Umsetzungen für jeden einzelnen Browsertyp oder für unterschiedliche Betriebssysteme.

Das Teilen anhand von Daten bringt ebenfalls kleinere User Stories. Im Kinobeispiel gibt es eine Suche nach Filmen auf der Webseite. Eine Userstory besagt, dass der Nutzer seine Suche über ein Formular einschränken kann. Mit allen Filtermerkmalen ist die Story aber zu groß. Der Kinobesucher könnte bei seiner Suche nach einem Film zum Bespiel erst nur nach Genre und Tag filtern. Eine weitere Userstory kümmert sich dann um den Filter nach Altersbeschränkung und Uhrzeit.

Manche User Stories beinhalten auch die Umsetzung von Regeln. Um ein Item splitten zu können, kann man eventuell diese Regel in eine eigene Userstory auslagern und die Ausgangsstory somit kleiner machen. Stellen wir uns vor der Kinobesucher möchte auf der Webseite Tickets für einen Film reservieren. Ein Akzeptanzkriterium dieser Anforderung besagt, dass er maximal 10 Tickets je Film reservieren kann, es also eine Beschränkung, eine Regel bei der Reservierung gibt. Genau diese kann man in eine eigene Story auslagern.

Ein Poster mit den fünf Techniken und einer kurzen Erklärung dazu erhält man als kostenlosen Download direkt auf der Website von Mountain Goat Software.

Einen anderen Weg um User Stories zu schneiden beschreibt das von Richard Lawrence erstellte Poster zum “User Stories aufteilen”, welches ich sehr gern weiter empfehle. Mit einem ja-nein-Fragen-Flowchart kann man ganz einfach verschiedene Wege und Möglichkeiten durchgehen, um einen effektiven Weg zum Splitten zu finden. Für mehr Informationen dazu lohnt sich ein Besuch auf dessen Website.

Auch wenn es anfangs nicht einfach ist, User Stories in akzeptabel große Items zu schneiden, so wird es mit ein wenig Übung von Mal zu Mal unproblematischer.