Suchen

Leicht zu lernen, schwer zu bewältigen User Stories in der Softwareentwicklung

Autor / Redakteur: Marcel Hölscher * / Stephan Augsten

User Stories sind schon lange kein Geheimtipp mehr in der Welt der Software-Entwicklung. Häufig wird der Begriff „User Story“ in direktem Kontext mit „Scrum“ verwendet – das Konzept lässt sich aber auch außerhalb reiner Scrum-Projekte anwenden.

Firmen zum Thema

Exemplarische Userstory mit Akzeptanzkriterien.
Exemplarische Userstory mit Akzeptanzkriterien.
(Bild: adesso)

So trivial und einfach das grundlegende Konzept hinter einer User Story auch erscheint, so schwer ist es doch am Ende, wirklich gute Stories zu verfassen. „Easy to learn and difficult to master“ – das ist zwar ein Zitat aus der Welt des Game Designs, trifft aber auch voll und ganz auf das Schreiben von User-Stories zu.

Die grundsätzliche Formel einer solchen Story wird den meisten Lesern sicherlich schon vertraut sein:

   „Als [Rolle] wünsche ich mir [Funktion] um [Nutzen]“

Ein ausformuliertes Beispiel dazu könnte lauten:

   „Als Kunde wünsche ich mir eine Übersicht über meinen Warenkorb, um die Bestellung kontrollieren zu können.“

Bei dem obigen Satz handelt es sich letztendlich jedoch nur um einen von drei Teilaspekten einer User Story. Ron Jeffries hat diese in einem seiner Artikel mit „Card“, „Conversation“ und „Confirmation“ benannt (Jeffries, 2001).

Durch Ausformulierung der oben beschrieben Formel beschreibt man die Kernanforderung dieser Story in einem Satz. Dieser wird auf die Vorderseite einer Karteikarte („Card“) geschrieben, für das Team sichtbar aufgehängt und dient dabei als Gedankenstütze sowie als Diskussionsgrundlage.

Genau hier setzt der zweite Aspekt an, die „Conversation“. Denn eines möchte die User Story nie sein: Eine bis ins kleinste Detail festgezurrte und in Stein gemeißelte Spezifikation an der niemand mehr rütteln darf. Viel lieber sieht sie sich als das Versprechen, zu gegebener Zeit zu reden, Gedanken, Meinungen und Bauchgefühle auszutauschen und die Anforderungen sukzessive weiter auszuarbeiten.

Aber: Das menschliche Gehirn ist oft ein Verräter und lässt wichtige Details nach einer gewissen Zeit gerne „verschwinden“. Man kommt also nicht darum herum, den einen oder anderen Aspekt zu verschriftlichen. Hier setzt der dritte Aspekt einer Story an, die „Confirmation“. Diese ist in größten Teilen verbal, kann aber um Dokumente ergänzt werden. Die besten Ergänzungen sind Beispiele; die besten Beispiele sind ausführbar (Jeffries, 2001).

Gemeint sind Akzeptanztests. Dies ist ein sehr elegantes Vorgehen: All die relevanten Details aus den „Conversations“ werden in Form von testbaren Akzeptanzkriterien definiert. Diese können zum einen entwicklungsbegleitend von der QA als Testgrundlage genutzt werden, zum anderen können sie quasi als „Definition of Done“ für die User Story dienen anhand deren der Product-Owner, Kunde oder Projektleiter (je nachdem welche Rolle hier dem tatsächlichen Projektsetup entspricht) die Story abnehmen kann.

Mehr ist nicht grundsätzlich besser

Egal ob die „Geschichte“ nun digital in einem Board erfasst wird oder Old School auf Karteikärtchen: Ihr Umfang sollte übersichtlich sein. Das bedeutet auch für die Anzahl der Akzeptanzkriterien, dass sie eine gewisse Menge nicht überschreiten sollte. Mit drei bis fünf Kriterien fühlt sich eine Story pudelwohl – danach setzt allmählich die „Anforderungs-Adipositas“ ein. Ab zehn sollte dringend geprüft werden, ob sich die Story nicht doch aufteilen lässt.

Exemplarische Userstory mit Akzeptanzkriterien.
Exemplarische Userstory mit Akzeptanzkriterien.
(Bild: adesso)

Wichtig ist hierbei auch, sich nicht in unnötigen Details zu verlieren: Es sollten nur diejenigen Akzeptanzkriterien verschriftlicht werden, die zur Wertsteigerung und Verdeutlichung der Story beitragen (Cohn, 2010, S. 90). In der vorangestellten Abbildung wird ein einfaches Beispiel einer User Story mit einigen Akzeptanzkriterien veranschaulicht.

Nun wurde verdeutlicht, was die Absicht hinter einer Userstory ist und wie sie formal aufgebaut ist. Aber wie kann ein engagierter Geschichtenschreiber jetzt verifizieren, ob er auch eine gute Geschichte erzählt hat? Hier haben es Romanautoren deutlich schwerer als Autoren von User Stories, denn Letzteren wird mit den INVEST-Kriterien ein probates Mittel gegeben, um die eigenen geistigen Höhenflüge auf ihre Qualität abzuprüfen.

Einige davon wurden bereits bei den Akzeptanzkriterien angeschnitten: User Stories sollten von ihrem Umfang her übersichtlich sein: Auf die Größe kommt es also an. Damit sind wir beim (S)mall-Kriterium. Aber wichtiger als die Anzahl der Akzeptanzkriterien ist die geschätzte Implementierungsdauer. Auch wurde festgehalten, dass die Akzeptanzkriterien zur Wertsteigerung der Story beitragen sollen – weitergesponnen bedeutet dieser Gedanke, dass die User Story an sich zur Wertsteigerung der Software dienen soll. Der „(V)alue“ einer Story ist also ebenfalls erfolgskritisch.

Überblick aller INVEST-Kriterien.
Überblick aller INVEST-Kriterien.
(Bild: adesso)

Hier nun ein grober Überblick über alle INVEST-Kriterien. Wie so häufig ist die Realität nicht so schön wie die Theorie. So auch bei den INVEST-Kriterien, denn diese können durchaus in Konflikt zu einander stehen.

Angenommen, innerhalb einer Mehrbenutzerapplikation sollen Nachrichten zwischen den Benutzern ausgetauscht werden können. Neben der eigentlichen Nachricht möchte man auch Anhänge anlegen können. Der Versand soll wahlweise per persönlicher Adressierung oder per Adressierung an eine Rolle erfolgen.

Dies alles in eine Userstory zu packen kann dafür sorgen, dass das Small-Kriterium verletzt wird. Ist dies der Fall, kann die eine große Story in drei kleinere aufgeteilt werden. In der ersten Story kann die Nachricht ohne Anhänge und per persönlicher Adressierung verschickt werden. Die zweite Story beinhaltet den Ausbau des Dialogs, so dass auch Anhänge hinzugefügt werden können und in der dritten Story wird dem User schließlich die Möglichkeit spendiert, zwischen Rollenadressierung und persönlicher Adressierung zu wechseln.

Nun haben wir drei gut schätzbare User Stories vorliegen – das Small-Kriterium ist also durchaus erfüllt – aber das Independent-Kriterium haben wir verletzt: Story Nummer 1 muss auf jeden Fall als erstes umgesetzt werden.

Hier muss der Storyschreiber abwägen: Ist die Story so groß, dass sie nicht mehr gut schätz- und handhabbar ist, so ergibt es Sinn, die Story aufzuteilen und die Verletzung des Independent-Kriteriums in Kauf zu nehmen. Falls sie aber ohne Aufteilung trotzdem noch gut innerhalb des Sprints realisierbar ist, lässt man sie am besten „am Stück“ und bereitet damit dem Product-Owner eine Freude, da dieser jetzt nicht mehr mit Argus-Augen darauf achten muss, dass die Stories in der richtigen Reihenfolge im Backlog liegen.

Das wichtigste Kriterium

Manch einer mag bei dem Anblick einer zu großen Story auch in Versuchung kommen, seine Geschichte dem Schichtenmodell seiner Architektur nach zu schneiden. So könnte es beispielsweise eine Story geben um die Datenbanktabelle MITARBEITER anzulegen. Davon ist dringend abzuraten, da damit eines der wichtigsten Kriterien verletzt werden würde: Der Value.

Der Kunde kann unter Umständen mit derart technisch getriebenen Stories nichts anfangen, damit wird ihm potentiell auch die Priorisierung erschwert. Bekommt er am Ende eines Sprints ein neues Inkrement geliefert, „bemerkt“ er noch nicht einmal etwas davon, dass diese neue Tabelle existiert.

Ein echter Wert existiert nur, wenn eine Story so formuliert wird, dass man nach deren Umsetzung ein präsentierbares neues Feature vorweisen kann – zum Beispiel das Anlegen eines neuen Mitarbeiters oder die Anzeige der Vorhandenen. Der Schnitt einer Story sollte sich also nicht am technischen Schnitt der Architektur orientieren sondern am fachlichen Schnitt der Features.

Generell sollte man alarmiert sein, wenn man beim Schreiben feststellt, dass man gerade technische Details „runterpinnt“. Eine Userstory sollte immer auf fachlicher Ebene bleiben. Sie beschreibt, was implementiert werden soll, nicht wie. Sie macht die Anforderungen klar, ist aber keine Lösungsbeschreibung. Hält man sich daran, dann kann auch ein nicht so Technik-affiner Kunde (oder Tester) etwas mit der Story anfangen.

So sind am Ende alle zufrieden: Der Entwickler, weil er weiß, was er implementieren muss, der Tester, weil er weiß, was er prüfen muss und der Kunde, weil er weiß, was er bekommt.

* Marcel Hölscher arbeitet seit 2008 für die adesso AG in Dortmund. Dort war er in einer Vielzahl von Projekten in unterschiedlichen Rollen im Java-Umfeld tätig (Entwickler, Scrum-Master, Projektleiter). Aktuell betreut er als Teilprojektleiter ein Projekt aus dem Public-Bereich.

(ID:46254432)