User Stories sind in agilen Methoden der de-facto Standard um Funktionalität zu beschreiben. Sie erzeugen Fokussierung aus die wichtigste Funktionalität und schnelle direkte Rückmeldung vom Kunden, besser und schneller als es viele Analysen tun. Stories sollen sicherstellen, dass jedes Feature einen klaren geschäftlichen Nutzen bringt.
Ein einfaches Projekt-Beispiel zum Einstieg: Es soll ein Webshop aufgebaut werden. Kunden bestellen Produkte online, können bezahlen und das Produkt wird geliefert.
»Webshop ist live und Kunden bestellen.« bedingt viele vernetzte Aktionen und ineinander greifende Funktionen. Da kann einiges schiefgehen.
Beim Ausführen des Tests aus Story 1 wird ein Fehler auftreten: der Adressat der Bestätigungsmail wurde als Peter User direkt in den Code geschrieben und nicht als Variable angelegt.
Also ist eine Erweiterung des Code zu implementieren und ein neuer Test zu erstellen: die E-Mail muss an den bestellenden User versandt werden und nicht an den in Story 1 im Code hinterlegten Peter User. Der erste Test wird also scheitern und wird so erweitert, dass eine Prüfung auf den bestellenden User geschieht. Vermutlich wird das Entwicklungsteam für das Feld Name nun eine Variable einführen und die Tests danach anpassen.
Zur Umsetzung dieser Story ist eine Erweiterung der Architektur nötig: bis jetzt gab es noch keine Anbindung einer Datenbank.
In der Diskussion zeigt sich schnell, dass diese Story ein zu großer Schritt ist: sie ist eher ein Epos (epic) als eine einzelne Geschichte und muss in kleinere überschaubare Pakete getrennt werden um leicht umsetzbar zu sein.
Schnell Rückmeldung erhalten: sind wir auf Kurs?
Das größte Risiko ist, den Bedarf zu verfehlen — zu liefern, was der Auftraggeber anders erwartet hat oder nicht braucht. Deshalb fokussieren wir mit der ersten Story genau darauf. In weiteren Stories adressieren wir weitere Stakeholder. Vor der Implementierung jeder Story wird in Abnahmekriterien genau definiert, was erfüllt sein muss, um das Ergebnis zu akzeptieren.Die erste Story
Peter Kunde kauft Produkt A
In dieser beschreibenden Formulierung ist der Nutzer und der Kontext klar und das Bedürfnis ist formuliert. Der Scope ist überschaubar: Es geht um Machbarkeit und Demonstration gegenüber dem Endbenutzer, noch lange nicht um Vollständigkeit oder Usability sondern um das Reduzieren von Unsicherheit und das Verstehen des Bedarfes. Die Formulierung dieser ersten Story ist einfach, allerdings für sich genommen zu einfach. In die Bedürfnisse kann man noch viel hineininterpretieren. Wir brauchen noch zwei weitere Elemente: Akzeptanzkriterien und eine gemeinsame Konversation.
Akzeptanzkriterien formulieren
Die Akzeptanzkriterien, mit denen geprüft werden wird, ob die Story auch korrekt umgesetzt ist, machen die Intention klarer:- Peter Kunde kann das Produkt A über den Browser online kaufen
- Nach dem Kauf erhält Peter eine Rückmeldung als E-Mail
Konversation
Die Story und ihre Akzeptanzkriterien haben nicht den Anspruch, eine selbsterklärende Spezifikation zu sein: sie bieten genug Stoff für eine zielführende Diskussion, um ein gemeinsames Bild zu erzeugen. Die Beteiligten können sich Notizen machen, das ist aber hier ausserhalb unseres Fokus.Umsetzung
Bei der Umsetzung konzentrieren wir uns auf die minimale Implementierung, die die Akzeptanzkriterien erfüllt: Wir wenden das Prinzip der Testgetriebenen Entwicklung an. Bevor eine einzige Zeile Code entsteht, wird ein Test formuliert, mit dem die Funktionalität des Code automatisiert geprüft werden kann. Wir schreiben also einen Test, der prüft: »Wird eine E-Mail an Peter Kunde verschickt?«. Dann wird die Funktionalität der Story in (in unserem Beispiel in extrem einfachen) Code umgesetzt. Funktionalität sowie Name und E-Mail-Adresse von Peter User stehen direkt im Code. Es fehlen Parameter oder Variablen — es soll für diese Story nur gezeigt werden, dass bestellt werden kann und eine Bestätigung verschickt wird. Es dauert nicht lange und das Entwicklungsteam hat die Story umgesetzt:- Peters Name und die Produktbezeichnung sind vorausgefüllt in einem Formular zu sehen.
- Es gibt einen “Bestellen” Button, den man klicken kann.
- Wird der Button geklickt, erhält der Käufer an die hinterlegte E-Mail-Adresse eine Bestätigung.
Die zweite User Story: Sabine Nutzer kauft Produkt A.
In der zweiten Story geht es darum, die erste Implementierung zu erweitern. Die Abnahmekriterien sind schon komplizierter:- Unterschiedliche User können ein Produkt online kaufen.
- Die E-Mail zur Bestätigung geht an den korrekten User.
Beim Ausführen des Tests aus Story 1 wird ein Fehler auftreten: der Adressat der Bestätigungsmail wurde als Peter User direkt in den Code geschrieben und nicht als Variable angelegt.
Also ist eine Erweiterung des Code zu implementieren und ein neuer Test zu erstellen: die E-Mail muss an den bestellenden User versandt werden und nicht an den in Story 1 im Code hinterlegten Peter User. Der erste Test wird also scheitern und wird so erweitert, dass eine Prüfung auf den bestellenden User geschieht. Vermutlich wird das Entwicklungsteam für das Feld Name nun eine Variable einführen und die Tests danach anpassen.
Story 3: eine Umsatzstatistik für den Auftraggeber
Mit der dritten User Story wird ein kaufmännisches Bedürfnis des Shopbetreibers bedient: wieviel Umsatz geschieht mit welchen Produkten? Die Abnahmekriterien für die dritte Story lauten:- Umsätze werden als Tabelle angezeigt.
- Die Tabelle der Umsätze kann nach Kaufdatum und Währung sortiert und gefiltert werden.
Zur Umsetzung dieser Story ist eine Erweiterung der Architektur nötig: bis jetzt gab es noch keine Anbindung einer Datenbank.
In der Diskussion zeigt sich schnell, dass diese Story ein zu großer Schritt ist: sie ist eher ein Epos (epic) als eine einzelne Geschichte und muss in kleinere überschaubare Pakete getrennt werden um leicht umsetzbar zu sein.