Am Anfang steht das Wort – In Scrum als User 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.
Letzteres ist insofern auch nicht weiter verwunderlich, da diese Texte wiederum von Entwicklern oder der Entwicklung nahestehenden Personen 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 von agilen Software Entwicklern wohl 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 Storys aus. Und das hat dann fatale Folgen.
Schlecht- aber vor allem unvollständig geschriebene Storys sind eines der häufigsten Gründe für das Scheitern von Scrum Projekten.
Zum Teil verantwortlich dafür ist wiederum oft die Misinterpretation eines weiteren Prinzips aus dem Manifesto: ‚Individuals and interactions 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 Storys 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 bzw. getroffen werden, beziehen sich auf die ihnen zugrunde liegenden Storys, denn um gute Software entwickeln zu können, braucht es eigentlich nicht viel 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…
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 Storys 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 Storys die einzelnen funktionalen Anforderungen repräsentieren.
In kleineren Projekten, wie zum Beispiel einem Webshop, kann auf die Epic-Ebene verzichtet werden. Auf die Storys 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, z.b. Architekten, Designer, aber schreiben sollte er sie selbst. Bevor ein PO mit dem Schreiben einer Story beginnt sollte er folgende Überlegungen anstellen:
1. Eine Story sollte aus rein funktionaler Perspektive geschrieben werden und bitte dabei den Unterschied zwischen Fachlichkeit und Funktionalität beachten, denn das ist bei Weitem nicht das Gleiche. Es wird ausschließlich das funktionale ‚was‘ beschrieben, nicht das technische ‚wie‘. Letzteres 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. Die Zielgruppe sind die Entwickler des Dev-Teams, nicht Stakeholder der Organisation.
3. Zum Zeitpunkt des Lesens (Sprint-Planning) werden in der Regel noch nicht alle Storys für das Gesamtprojekt vorliegen, die Story muss es also irgendwie schaffen, die Vision für das Gesamtprodukt oder zumindest für das Epic 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 bekommen die Software nur scheibchenweise beschrieben und sollen aber in jedem Sprint idealerweise funktionsfähige Software abliefern. Die Storys 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 Storys 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 möglichst validen 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 ohne dass er für den Geschäftszweck keinen Sinn mehr ergibt (z.B. die Änderung einer Adresse in einem Bestellprozess, das Checkin auf einer Airline-Website). Er ist also sehr klein aber vertikal und schließt Frontend, Backend und Datenkommunikation- und Speicherung mit ein.
b) Der Elementarprozess sollte funktional end-2-end testbar sein.
Die Beschreibung solcher Elementarprozesse im Rahmen der Storys 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 User Story in Scrum: 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 geeignete 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.
Die Motivation wird aus der Perspektive des Product Owners geschrieben. Er vermittelt als Auftraggeber seine Gründe, warum er diese Story braucht.
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, dann 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, also den Scope, 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 Storys aus.
Die Art und Weise wie eine User 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 Refinements 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 Storys 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 User 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.
Während die Motivation aus der Perspektive des PO, also des Auftraggebers geschrieben wird, empfiehlt es sich, die Description aus der Perspektive des Anwenders zu schreiben. Daher sieht man hier den Stil „Als User möchte ich… Zu diesem Zweck steht mir …. zur Verfügung. Wenn ich … tue, dann passiert…“ In diesem Stil sind Daten, Prozesse, Interfaces enthalten und aus der Perspektive des Anwenders beschrieben. Die Perspektive des Anwenders hilft in jedem Fall dem PO auch, in der Beschreibung funktional zu bleiben und „funktional“ wiederum bedeutet am „Business Value“ orientiert. Beziehungsweise hilft es zu verhindern, dass Backlogs mit technischen Storys geflutet werden.
3. Acceptance Criteria (AC):
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 meist von wenig erfahrenen PO’s gemacht wird, ist zu sagen: „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, nachdem sie die Description gelesen haben. Der Scope der Story sollte vollständig in der Description beschrieben werden, die AC’s brauchen wir für etwas anderes.
PO’s machen es dennoch recht oft, weil es nun mal gar nicht so leicht ist, gute Acceptance Critera zu schreiben. Dafür habe ich daher zwei Empfehlungen:
Die erste ist: Zwingen Sie sich zu jeder Story mindestens 3 bis 5 Acceptance Criteria zu formulieren. Vergessen Sie dabei vor allem auch nicht die sogenannten ‚Non-Functional-Requirements‘ (NFR), 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. Eigentlich sind die NFR’s natürlich besser in der Definition of Done aufgehoben, da sie nicht nur für eine Story, sondern für die gesamte Anwendung gelten.
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 Criteria überprüft werden. Von Motivation über Description und Acceptance Criteria bis zu den Testfällen liest sich das so:
Scrum User Story:
- Warum will ich dieses Feature haben (Motivation)
- Was soll implementiert werden (Description)
- Wann ist die Implementierung erfolgreich (Acceptance Criteria)
- 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 Criteria 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. Während die Motivation die Perspektive des PO’s beschreibt und die Description die Perspektive des Anwenders, führen die Acceptance Criteria und die Testfälle noch eine dritte und sehr wichtige Perspektive ein, nämlich die Perspektive der Anwendung selbst.
Wir hatten oben gesehen, dass die Motivation die Perspektive des PO wiedergibt und die Description aus der Perspektive des Anwenders geschrieben wird. Die Testfälle führen eine weitere Perspektive ein, nämlich die der Anwendung selbst. Damit beschreibt eine Story einen zu implementierenden Gegenstand aus drei verschiedenen Perspektiven, was extrem hilfreich ist um sie auf Konsistenz, Business Value, Funktionalität und Machbarkeit überprüfen zu können. So können Storys leicht verstanden und dann auch leichter entwickelt werden.
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 Criteria sogar weitgehend sparen, zumindest extrem verkürzen.
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. Gerade in SAFe und dem dort zitierten ScrumXP wird diese Technik wieder sehr hervorgehoben und korrespondiert dort mit einem der Grund-Prinzipien der Build-in-Quality.
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, vor allem aber frühe 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!
