15 Jun
Scrum story

Die Story in Scrum und warum sich die Mühe lohnt

AM ANFANG STEHT DAS WORT – IN SCRUM ALS STORY

Softwareentwickler schreiben nicht gerne Texte. Dies gehört zu einer der universellsten Tatsachen seit Erfindung der Softwareentwicklung. Übrigens lesen sie auch nicht gerne Text, jedenfalls nicht wenn es sich um technische Dokumentationen oder Spezifikationen handelt, die für ihr Projekt wichtig oder relevant wären. Oft gilt das auch für die Story. Letzteres ist insofern auch nicht weiter verwunderlich, da diese Texte wiederum von Entwicklern geschrieben wurden, die, wie oben erwähnt gar nicht gerne Texte schreiben, was sich natürlich unmittelbar auf die Qualität der Texte auswirkt. Ein Teufelskreis. Man könnte meinen, SCRUM ist entweder von solchen frustrierten Entwicklern erfunden worden, oder von Projektleitern, die Mitleid mit Entwicklern hatten, oder es ihrerseits schlicht aufgegeben haben, Dokumentationen einzufordern, ohne realistische Aussicht diese jemals in angemessener Qualität zu bekommen. Passend dazu dürfte das Prinzip ‚working software over comprehensive documentation‘ aus dem ‚MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT‘, zumindest in meiner professionellen Praxis der wohl von Software Entwicklern meist zitierte Satz sein.

Auch wenn die oben genannten Akteure in gewisser Weise sogar recht haben, wirkt sich unglücklicherweise die Mentalität viel zu oft auch auf das Schreiben von Stories aus. Und das hat dann fatale Folgen.

Schlecht- aber vor allem unvollständig geschriebene Stories sind eines der häufigsten Gründe für das Scheitern von SCRUM Projekten.

Zum Teil verantwortlich dafür ist wiederum oft die Missinterpretation eines weiteren Prinzips aus dem Manifesto: ‚Individuals and itneractions over processes and tools‘ bzw. ‚The most efficient and effective method of conveying information to and within a development team is face-to-face conversation ‘. Beides klingt auf dem ersten Blick nicht gerade nach guten Argumenten für ein Plädoyer für gut geschriebene Stories. Allerdings und wie wir später noch sehen werden, muss erstens eine gut geschriebene Story nicht unbedingt sehr lang sein, und zweitens basieren die beiden oben genannten Prinzipien auf gut geschriebenen Stories und beschreiben, wie der Prozess im Anschluss daran aussehen soll. Und da gibt es dann noch einiges zu klären, angefangen bei Architektur-Entscheidungen über Implementierungs-Plan, CI-Strategie, Test-Plan, Deployment-Strategie, Know-how-Transfer, usw. Alles Angelegenheiten, in denen direkte Kommunikation der beteiligten Akteure absolut unablässig ist und wesentliche Vorteile der SCRUM Methode zum Vorschein bringt.

Die Story, als geschriebenes Artefakt bildet für diese Kommunikation die Grundlage und den verlässlichen Bezugspunkt und genau darum erfordert sie besonderes Augenmerk.

Nochmal, nahezu alle Prozesse und Entscheidungen, die in einem SCRUM Projekt stattfinden (Prozesse) bzw. getroffen (Entscheidungen) werden beziehen sich auf die ihnen zugrunde liegenden Stories, denn um gute Software entwickeln zu können, braucht es eigentlich nicht viel mehr (um sie warten und betreiben zu können, braucht es allerdings dann später doch noch etwas mehr). Über den Stellenwert einer Story im SCRUM Prozess ist jetzt genug gesagt worden. Nun kümmern wir uns um die Frage, wie denn eine gute Story geschrieben werden sollte.

JETZT GEHT’S LOS… ODER NOCH NICHT?

Eine Story ist Teil eines Product-Backlogs, welches die Gesamtheit der für das Software Projekt relevanten funktionalen Anforderungen abbildet. In großen Entwicklungsprojekten empfiehlt es sich eine zweistufige Hierarchie mit Epics und Stories einzuführen. Epics repräsentieren darin allgemein gesprochen ganze Software-Module bzw. aus funktionaler Sicht übergeordnete Geschäftsprozess Gruppen (z.B. innerhalb eines ERP Systems das Bestellwesen, das Rechnungswesen, das CRM oder die Lagerhaltung) während sie Stories die einzelnen funktionalen Anforderungen repräsentieren. In kleineren Projekten wie zum Beispiel einem Webshop kann auf die Epic-Ebene verzichtet werden. Auf die Stories kann niemals verzichtet werden.

Ich gehe hier darauf ein, wie eine gute Story geschrieben werden sollte. Für Epics gilt im Wesentlichen das gleiche und alles was wir hier über die Story sagen, kann leicht auf die Epics übertragen werden, die Gewichtungen können dabei leicht variieren.

Eine Story wird in der Regel vom Product Owner (PO) geschrieben, mindestens aber trägt er für die Story die alleinige Verantwortung und diese ist nicht delegierbar. Der PO darf sich beim Schreiben der Story selbstverständlich jedweder Hilfe bedienen. Bevor ein PO mit dem Schreiben einer Story beginnt sollte er aber mindestens folgende Überlegungen anstellen:

1. Eine Story sollte aus rein funktionaler Perspektive geschrieben werden. Es wird ausschließlich das ‚was‘ beschrieben, nicht das ‚wie‘. Das ‚wie‘ obliegt später dem Entwicklerteam in all den oben genannten Folgeprozessen, für die dann face-to-face Kommunikation so wichtig wird.

 

2. Die Story soll später von Menschen (Entwicklern) gelesen und verstanden werden und – ganz wichtig – im Idealfall soll es neben der Story nichts weiter an Text geben müssen. Die Story muss also die funktionale Anforderung vollständig und zielgruppengerecht beschreiben.

 

3. Zum Zeitpunkt des Lesens (Sprintplanning) werden in der Regel noch nicht alle Stories für das Gesamtprojekt vorliegen, die Story muss es also irgendwie schaffen, die Vision für das Gesamtprodukt erkennbar zu machen, damit wesentliche Architekturentscheidungen schon zu diesem frühen Zeitpunkt getroffen werden können.

 

4. Die Entwickler haben es ohnehin schon schwer genug; sie müssen bekommen die Software nur scheibchenweise beschrieben und sollen aber in jedem Sprint idealerweise funktionsfähige Software abliefern. Die Stories müssen diesen Prozess unterstützen und nicht verhindern. Sie sind nicht einfach nur Requirements, sie sind Teil des gesamten Prozesses und der Story muss das Bemühen anzusehen sein, dass der PO diesen Prozess unbedingt unterstützen möchte. Das klingt zwar etwas „schwammig“ aber den meisten Stories sieht man dieses Bemühen nicht an. Lesen Sie mal bei Kants Kritik der reinen Vernunft nach. Das Thema ist nicht trivial, aber Sie lesen in jeder Zeile das unermüdliche Bemühen des Herrn Kant, den Leser wirklich bei der Hand zu nehmen und ihm das ganze Verständlich zu machen. Ein Wesenszug, den sich Herr Hegel schon nicht mehr wirklich zu Eigen gemacht hat. Da wird die Welt schon ziemlich von oben herab beschrieben (wenn auch im Kern nicht weniger geistreich).

 

5. Erster Meilenstein bei der Verarbeitung einer Story ist im Sprint Planning II das Abgeben eines Commitments in Form einer Schätzung. Die Story muss also bewertbar sein. Außerdem wäre es zweckmäßig, die Möglichkeit zu eröffnen, später auch die Velocity des Teams zu messen. Damit wird sie tatsächlich Teil des Ganzen Prozesses und bildet nicht nur einfach die funktionale Anforderung ab. Um das zu erreichen, sollte jede Story einen- und nur einen funktionalen Elementarprozess abbilden. Dieser ist durch folgende Eigenschaften gekennzeichnet:

 

a) Ein Elementarprozess ist ein in sich geschlossener Geschäftsprozess und sollte nicht weiter zerlegbar sein (z.B. die Änderung einer Adresse in einem Bestellprozess, das Checkin auf einer Airline-Website).

b) Der Elementarprozess sollte funktionale end-2-end testbar sein.

Die Beschreibung solcher Elementarprozesse im Rahmen der Stories gibt Ihnen die Möglichkeit bei der Schätzung leicht jede Metrik wie Story-Points, Function-Points oder Zeit anzuwenden und wird den gesamten SCRUM Prozess massiv unterstützen. Sie sollten auf diese Vorteile keinesfalls verzichten.

DIE GUTE STORY: SO SIEHT SIE AUS

Eine Story sollte sich mindestens aus vier inhaltlichen Bestandteilen aufbauen, die ich nachfolgend kurz Beschreibe:

1. Motivation:

Die Motivation beschreibt, warum diese Story überhaupt gebraucht wird, welchen Wert das darin beschriebene Feature aus Sicht des Product Owners (PO) für das Produkt hat aber auch welchen Stellenwert diese Story im Entwicklungsprozess hat (z.B. der erste Proof of Concept für ein Modul oder die abschießende Story, die die finale Fertigstellung des Projektes bedeutet). Da im Product Backlog prinzipiell jede Story für sich alleine steht, der PO den Entwicklern gleichermaßen Vision des Produktes und Leitfaden der Entwicklung liefern sollte, ist die Motivation der am besten geeignetste Ort, genau das zu tun. Die Vision des Produktes zu verstehen, ist für Entwickler unglaublich wichtig, wenn es darum geht weitsichtige Architekturentscheidungen zu treffen obwohl ja gerade in frühen Phasen der Entwicklung noch gar nicht alle Stories vorliegen. Meiner Erfahrung nach ist eine ausführliche Beschreibung der Motivation fast wichtiger als die Beschreibung des Features an sich. In der Regel wende ich dafür mehr Text auf, als PO kann ich damit meine eigene Intention sehr gut noch einmal überprüfen und im Sprint Planning zur Diskussion stellen. Wer sich über die Motive seiner Handlung im Klaren ist, kann sein Handeln sehr gut Planen. Genau das gilt für das Schreiben einer Story, wenn ich meine Motivation klar dargelegt habe, dass ist die Beschreibung des Gegenstandes in der Regel wesentlich einfacher und vor allem konsistenter.

2. Description:

Auf die Motivation folgt die bereits oben angesprochene Description, die den Gegenstand dessen, was entwickelt werden soll beschreibt. Auf das ‚Warum‘ (Motivation) folgt also das ‚Was‘ (Description). Oft werde ich gefragt, wie eine perfekte Description aussehen soll, wieviel Text, welcher Stil, etc. Eine klare Antwort auf diese Frage gibt es nicht, und zwar aus folgendem Grund: In meinem Beitrag über DAS WESEN VON SCRUM hatte ich ‚Communication‘ als einen der vier wesentlichen Grundprinzipien für SCRUM gekennzeichnet. Dies drückt sich in besonderer Weise in der Beschreibung der Stories aus. Die Art und Weise wie eine Story beschrieben wird, drückt zu allererst den Stand der Kommunikation zwischen Team und PO aus. Und diese verändert sich mitunter massiv im Verlauf eines Projektes, zumindest sollte es so sein. Ein neues, junges, unerfahrenes Team zu Beginn eines Projektes benötigt ganz bestimmt sehr viel detaillierte Beschreibungen in einer Story als ein Team, welches die Projektvision bereits perfekt adaptiert hat, die Gedankengänge des PO’s sehr gut kennt und zu dem sehr tief in der Materie steckt. Letzterem genügen mitunter ein paar einfache Skizzen und während des Plannings oder Groomings ein paar begleitende Kommentare.

Gerade weil sich diese Kommunikation nach einigen Sprints und gut durchgeführten Retrospektiven ändern wird, macht es keinen Sinn – und ist sogar kontraproduktiv – vor Projektstart bereits alle Stories fertig beschrieben zu haben. Planen Sie besser 1 bis maximal 3 Sprints im Voraus, abhängig auch von der gewählten Länge eines Sprints.

In der Description einer Story sollte alles erlaubt- und nahezu nichts verboten sein. Ob Sie ein UML Diagramm verwenden oder Volltext schreiben, ein Mockup erstellen oder Links zur Konkurrenz nutzen bleibt ganz Ihnen überlassen. Es muss zweckmäßig im oben genannten Sinn bleiben. Grundsätzlich empfehle ich folgende Überlegung: IT im ganz Allgemeinen besteht aus drei Dingen: Daten, Prozessen und Interfaces. Wenn Sie in der Description angeben welche Daten mit welchen Prozessen über welche Interfaces verarbeitet werden, dann können Sie eigentlich nicht mehr so ganz falsch liegen.

3. Acceptance Criterias:

Auf die Description folgen die Akzeptanzkriterien, die auflisten wann es gut ist, was da entwickelt wurde bzw. unter welchen Umständen die Implementierung der Story abgenommen wird. Der häufigste Fehler der hier von wenig erfahrenen PO’s gemacht wird ist zu sagen, dass das Akzeptanzkriterium ist, dass alles was Implementiert wurde auch funktioniert, also quasi eine erneute Auflistung der Beschreibung. Das ist zwar einfach und sehr naheliegend, aber nicht zielführend, denn das hätten sich die Entwickler eigentlich auch denken können. Aber was ist nun mein Tipp um gute Acceptance Criterias zu schreiben. Ich habe zwei Empfehlungen. Die erste ist, zwingen Sie sich zu jeder Story mindestens 3 bis 5 Acceptance Criterias zu formulieren. Vergessen Sie dabei vor allem auch nicht die sogenannten ‚Non-Functional-Requirements‘, also, dass die Funktion auf einer bestimmten Umgebung mit erwarteten Reaktionszeiten läuft, oder dass ein durchschnittlicher Test-User die Anwendung intuitiv bedienen kann, etc. Meine zweite Empfehlung hat etwas mit dem vierten und jetzt folgenden Abschnitt zu tun, daher erkläre ich diese gleich unten.

4. Test Cases:

Testfälle beantworten die Frage, wie die Acceptance Criterias überprüft werden. Von Motivation über Description und Acceptance Criterias bis zu den Testfällen liest sich das so: Warum will ich dieses Feature haben (Motivation), Was soll implementiert werden (Description), wann ist die Implementierung erfolgreich (Acceptance Criterias) und wie überprüfe ich das (Test Cases). So gelesen, ergeben die vier Bestandteile eine logische Reihenfolge. Die oben genannte zweite Empfehlung für das Schreiben von Acceptance Criterias ist also folgende: Überlegen Sie sich, wie Sie das Feature testen würden und was Sie als Ergebnis der Tests erwarten würden. Und dann stellen Sie zwischen den Testfällen und den Acceptance Criterias eine Entsprechung her. Bei der Erstellung der Testfälle achten Sie darauf, dass nicht nur der good-case getestet wird, sondern auch alle Arten von abweichendem Verhalten der Anwendung oder der Anwender.

DARF’S AUCH ETWAS MEHR SEIN?  TESTDRIVEN DEVELOPMENT

Zum guten Schluss dieses Artikels, jetzt noch ein Tipp bzw. ein Trick über den Sie zumindest mal nachdenken sollten. Ich hatte oben die vier Komponenten einer Story als eine logische Reihenfolge beschrieben.

Wenn Sie dem Projekt, Ihren Entwicklern, der Performance und der Qualität wirklich einen Gefallen tun wollen, dann verändern Sie die Reihenfolge und gehen nach der Motivation von unten nach oben.

Sie beschreiben also nach der Motivation sofort die Testfälle. Streng genommen können Sie sich dann die Description und die Acceptance Criterias sogar sparen. Das Ganze nennt sich dann ‚testdriven development‘, die Königsdisziplin der Softwareentwicklung, denn sie ermöglicht sehr schnelles und vor allem sehr präzises Entwickeln. Kennt ein Entwickler bereits die Testfälle, gegen die er entwickeln soll und kann davon ausgehen, dass diese auch vollständig sind, bleiben in der Regel keine Fragen offen und sie erhalten am Sprintende sehr gute Resultate. Allerdings ist dieses ‚testdriven development‘ in der praktischen Wirklichkeit so selten anzutreffen wie rotes Quecksilber, gleich einem Mythos. Das liegt in der Regel daran, dass POs das Schreiben von Testfällen scheuen wie der Teufel das Weihwasser. In der Tat ist das kontinuierliche Schreiben von vielen Testfällen keine triviale Angelegenheit. Es braucht Übung, es entlarvt alle konzeptionellen Schwächen oder Informationslücken des PO, es erfordert eine sehr genaue Kenntnis des zu implementierenden Geschäftsprozesses und man muss hier sehr diszipliniert arbeiten. Es ist technisch an sich nicht schwierig, macht aber sehr viel Mühe und ich habe noch nicht viele POs gesehen, die ein solches Commitment zu einem Projekt gegeben haben, dass sie mit ‚patriotischer‘ Freude diese Mühe gerne auf sich genommen haben.

Überzeugen Sie mich bitte vom Gegenteil!

Leave a Reply

Your email address will not be published. Required fields are marked *