In den agilen Software Engineering Projekten nennen die Teams ihre Tickets häufig „User Story“. Hinter diesem Begriff verbirgt sich ein Konzept, das eine agile Denkweise reflektiert. Oft erlebe ich beim Lesen von Storys jedoch Unklarheit und fehlendes Hintergrundwissen. Auf der anderen Seite sollte man nie zu dogmatisch sein und Konzepte hinterfragen. Dieser Artikel soll als kleine Referenz dienen, was unter einer User Story verstanden werden kann.
In seinem Buch User Stories Applied (2004) definiert Mike Cohn eine User Story frei übersetzt wie folgt:
Eine User Story beschreibt eine Funktionalität, die für einen Anwender oder Käufer eines Systems oder einer Software wertvoll ist. User Storys werden anhand dreier Aspekte zusammengestellt:
- Eine schriftliche Beschreibung der Story, die für die Planung und als eine Erinnerung verwendet wird.
- Konversationen über die Story, aus denen die Details herausgeschnitten werden können.
- Tests, die Details vermitteln und dokumentieren und verwendet werden können, um den Abschluss der Story zu bestimmen.
Diese drei Bestandteile machen eine User Story aus und dürfen demnach nicht fehlen. Im Folgenden will ich näher auf sie eingehen.
Beschreibung einer User Story
Die schriftliche Beschreibung spiegelt einen für Anwender:innen gewonnenen Wert wider. Dieser Punkt gerät aus meiner Erfahrung immer weiter in den Hintergrund: Oftmals vermischen Entwickler:innen eine technische Verbesserung mit neuen Funktionen. Dieses Paradigma ist durchaus vorteilhaft, kann aber den Fokus auf den Wert für die Anwender:innen ablenken. Auch wenn sich mit zunehmender Lebenszeit eines Softwaresystems der Modernisierungsdruck erhöht, bleibt die Schaffung eines Wertes von zentraler Bedeutung. Entsprechend gibt es definitorisch keine in sich geschlossene Story, um bspw. einen neuen Service zu bauen oder ein neues Framework zu verwenden. Derartige Schritte können jedoch Bestandteile einer Story sein, die anhand eigener Aufgaben spezifiziert sind.
Folgende Beispiele veranschaulichen, welche Werte eine User Story liefern kann:
- Die Anwenderin kann ein Produkt bestellen.
- Die Anwenderin kann eine Nachricht versenden.
- Die Anwenderin kann einen Auftrag stornieren.
Details einer User Story
Aus den Konversationen über eine User Story kristallisieren sich Details über ihre Umsetzung heraus. Diese Details helfen dabei, eine (testgetriebene) Implementierung zu beginnen und die Tests daran auszurichten. Bei den Details geht es um feingranulare Teilaspekte, um den Wert einer User Story den Anwender:innen zu ermöglichen. Oft lohnt es sich, die Details in Aufgabenpakete zu bündeln und dort zu beschreiben. Es ist für die Entwicklung von entscheidendem Vorteil, keine zu großen User Storys zu haben, da sich kleine Storys gut parallelisieren lassen und fertige User Storys schneller getestet und in Produktion gehen können.
Beispiele für Details sind etwa
- Die Produktbestellung erfolgt über einen Warenkorb.
- Im Warenkorb kann die Anzahl der gewählten Produkte variiert werden.
- Nach Eingabe der Rechnungs- und Lieferadressen erhält die Anwenderin die Möglichkeit, Zahlungsinformationen anzugeben.
- Sofern alle Bestellinformationen angegeben wurden, wird der Auftrag an das Bestellsystem gegeben.
Akzeptanztests
Schließlich zählen zu einer User Story die Akzeptanztests. Sie verifzieren, ob der Wert einer Story auch wirklich entsteht. Für mich sind diese Tests sehr nützlich, denn sie zeigen auf, an was gedacht werden muss: Randbedingungen, Szenarien, Fehlerfälle etc. Hier beginnt im Grunde die testgetriebene Entwicklung, denn wer sich im Vorfeld überlegt, was geprüft wird, gibt bei der Umsetzung umso mehr derauf acht. Insbesondere die Erwartungen, auch auf der fachlichen Seite, können geschärft werden. Es erlaubt einen eindeutigen Blick darauf, was nach Umsetzung einer Story möglich sein wird und was nicht. Auch lassen sich derartige Akzeptanztests gut lesen.
Um den Aufwand bei der Erstellung einer User Story nicht über technische Grenzen hinaus gehen zu lassen formulieren viele meiner Kunden auch Akzeptanzkriterien. Dies sind Kriterien, anhand derer eingeschätzt werden kann, ob eine User Story abgeschlossen ist. Im Unterschied zu den ausführlicheren Akzeptanztests sind sie weniger detailliert, z.B.
- Eine Bezahlung mit einem Internetbezahldienst ist möglich.
- Eine Bezahlung per Kreditkarte ist möglich.
- Eine Bezahlung via EC ist möglich.