Im vorherigen Artikel habe ich User Stories als Mittel zur Anforderungserfassung vorgestellt. Wir haben gelernt, dass eine User Story eine geforderte Funktion in einem kurzen Satz beschreibt, so dass ein Wert für den User erkennbar ist. Der User kann dabei der Endanwender sein oder aber der Käufer der Software – oft handelt es sich dabei um unterschiedliche Personen mit unterschiedlichen Interessen – ich gehe später noch einmal darauf ein. Neben dem Aspekt der Beschreibung hat eine User Story zwei weitere Aspekte, nämlich das Gespräch und die Akzeptanztests. Nur unter Berücksichtigung aller drei Aspekte lässt sich mit User Stories arbeiten. Doch was zeichnet eine gute User Story aus? Wann ist eine Story so “reif”, dass sich damit sinnvoll arbeiten lässt? Beschäftigen wir uns im Folgenden mit den Eigenschaften einer guten Story.

Unabhängig

Zunächst sollte beim “schneiden” der Anforderungen in User Stories darauf geachtet werden, dass es zwischen den Stories keine Abhängigkeiten gibt. Eine Story sollte in der Regel losgelöst von anderen Stories bearbeitet und umgesetzt werden können, andernfalls ergeben sich sehr schnell Probleme bei der Priorisierung. Oft findet sich ein passender Weg, die Stories geschickt aufzuteilen, so dass diese tatsächlich unabhängig voneinander sind. Manchmal lässt es sich nicht vermeiden und es bleiben zwei Möglichkeiten: Die voneinander abhängigen Stories werden zu einer größeren Story zusammengefasst oder – wenn man das nicht möchte – wird der Aufwand der abhängigen Story mit zwei unterschiedlichen Werten geschätzt – einmal unter der Annahme, dass die andere Story davor bearbeitet wurde und einmal danach. Diese Optionen sollten jedoch die Ausnahme sein, nicht die Regel.

Verhandelbar

Die Beschreibung einer Story dient der Erinnerung an die geforderte Funktionalität und enthält damit nicht alle relevanten Details. Diese werden im Gespräch mit dem Kunden oder dem diesen vertretenden Product Owner verhandelt. Sind bereits bei der Erfassung einer Story wichtige Details bekannt, dann sollten diese natürlich auch als Anmerkung notiert werden und dienen dann als Gedächtnisstütze für das Gespräch. In der agilen Softwareentwicklung sind das Backlog Grooming und bei Scrum der erste Teil des Sprint Planning Meetings der richtige Zeitpunkt, um Details auszuhandeln. Die Herausforderung beim Schreiben von User Stories ist, die richtige Menge an Details in die Beschreibung (und die Anmerkungen) aufzunehmen. Werden Details dann in der Besprechung beschlossen, werden diese zu Akzeptanztests.

Hier ein Beispiel für eine Story samt Anmerkungen und Akzeptanztests:

Im Onlineshop kann ein Kunde seinen Warenkorb mit Kreditkarte bezahlen.

Anmerkung: Werden Barclaycards akzeptiert?
Anmerkung zur UI: Der Kartentyp kann anhand der Nummer abgeleitet werden, daher ist keine separate Auswahl notwendig.

Akzeptanztests:

  • Teste, dass Bezahlung mit Visa, MasterCard und AmEx möglich ist
  • Teste, dass die Bezahlung mit Diners Club abgewiesen wird
  • Teste, dass mit korrektem Card Validation Code (CVC) bezahlt werden kann, nicht jedoch mit falschem oder fehlendem CVC
  • Teste, dass abgelaufene Karten abgewiesen werden
  • Teste, dass sowohl Beträge unter als auch über 100 EUR akzeptiert werden

Werthaltig für Anwender oder Käufer

Häufig spricht man beim Wert einer Story vom Business Value bzw. vom Geschäftswert. Dieser Wert spiegelt nicht immer den Wert einer Story für den Endanwender wieder. Oft ist es so, dass eine große Anzahl an Stories für den Endanwender nicht oder kaum von Bedeutung sind, wohl aber im Interesse des Käufers der Software sind. Eine verschlüsselte Dateiablage oder eine Mandantenfähigkeit sind für den Anwender der Software in der Regel unwichtig, ihn interessiert eher, dass er nach den gewünschten Daten suchen kann oder eine übersichtliche Darstellung von Informationen hat und diese ausdrucken kann. Der Käufer einer Software, zum Beispiel die Firma oder deren IT-Abteilung, könnte dagegen sehr großes Interesse daran haben, dass die Dateien vor Fremdzugriff geschützt sind. Um verschiedene Interessensgruppen zu berücksichtigen, diese Berücksichtigung sichtbar zu machen und auch um bei der Erfassung die verschiedenen Interessen abzudecken kann in den Stories mit “Personas” gearbeitet werden. Ich werde an dieser Stelle jedoch verzichten, detaillierter auf Personas einzugehen und verweise auf die Artikel von Alan Cooper [2] und Jared M. Spool [3].

Unbedingt zu Vermeiden sind dagegen Stories, die sich nur auf die Technik und die Belange des Entwicklers beschränken und damit nur von ihnen bewertet werden können. Auch wenn die Intention für diese Stories eine gute ist, dann sollten diese dennoch so formuliert werden, dass der Wert für den Kunden ersichtlich wird. Mike Cohen führt in seinem Buch [1] folgendes Beispiel an: 

Alle Verbindungen zur Datenbank erfolgen über einen Connection Pool.

Diese offensichtlich rein technische Story kann aus Kundensicht nicht bewertet werden. Cohen schlägt als Alternative beispielsweise folgende Formulierung vor:

Bis zu 50 User sollten die Anwendung mit einer Datenbanklizenz für fünf Plätze nutzen können.

Mit dieser Formulierung kann der Kunde durchaus etwas anfangen – er ist dadurch in der Lage, die Story zu bewerten und zu priorisieren. Ebenso wie technische Annahmen (z.B. die Nutzung eines Connection Pools) aus den Stories herausgehalten werden sollten, sollte auch versucht werden, auf Angaben zur Benutzeroberfläche (möglichst lange) zu verzichten.

Schätzbar

Auch von Entwicklern wird gefordert, ihre Arbeit zu planen und zurückzumelden, bis wann bzw. mit welchem Aufwand die Umsetzung erfolgen kann. Dies erfolgt dann in einer Schätzung von Dauer oder Aufwand, z.B. in Form von Story Points. Ich selbst bin kein großer Freund von Zeitschätzungen, sondern präferiere die Schätzung des Aufwands in einer abstrakten, relativen Größe. Dem Einwand, dass dann nicht geplant werden kann, was bis wann umgesetzt wird, kann man mit der “Velocity” des Entwicklungsteams begegnen. Die Velocity eines Teams ist die Summe an Story Points, die von diesem in einer Entwicklungsiteration abgearbeitet werden kann. Somit lässt sich indirekt wieder eine zeitliche Abschätzung ableiten.

Aus Sicht eines Entwicklers kann es jedoch drei Gründe geben, weshalb eine Story nicht schätzbar ist:

  1. Dem Entwickler fehlt das Domänenwissen
  2. Dem Entwickler fehlt das technische Wissen
  3. Die Story ist zu groß/umfangreich

Dem fehlenden Domänenwissen kann mit einem Gespräch mit dem Kunden begegnet werden und wenn eine Story zu groß ist, dann bleibt sie so lange ungeschätzt, bis sie in kleinere Stories aufgeteilt wurde. Dem fehlenden technischen Wissen dagegen lässt sich nur begegnen, indem dieses Wissen zumindest soweit aufgebaut wird, dass man eine Idee davon erhält, mit welchem Aufwand sich die Story umsetzen lässt. Von einem oder mehreren Entwicklern wird dann in einem kleinen, zeitlich beschränkten (timeboxed) Experiment das notwendige Wissen aufgebaut – im Extreme Programming wird ein solches Experiment “Spike” genannt. Somit werden aus der nicht abschätzbaren Story zwei, da noch die Story für den Spike hinzukommt. Da der Spike durch eine maximale Zeitdauer limitiert ist, lässt sich die Spike-Story auch schätzen und somit einplanen.

Klein

Die Größe einer Story ist entscheidend, ob sie in eine Entwicklungsiteration eingeplant werden kann. Ist die Story zu groß, kann sie entweder nicht abgeschätzt werden oder sie passt womöglich nicht (sinnvoll) in eine Iteration. Eine große Story (bzw. ein Epic) ist entweder eine zusammengesetzte Story oder eine komplexe Story.

Eine zusammengesetzte Story besteht aus mehreren kürzeren Einzelstories und kann somit weiter aufgeteilt werden. Es kann durchaus passieren, dass man erst im Verlauf des Entwicklungsprojekts erkennt, dass es sich bei einer Story mit vermeintlich angemessenen Umfang, doch um eine große zusammengesetzte Story handelt. Bei der Aufteilung muss man jedoch wieder aufpassen, dass die Granularität angemessen bleibt und die Stories nicht zu klein werden. Sehr kleine Stories können dagegen in einer größeren zusammengefasst werden. Eine angemessene Größe ist erreicht, wenn die Story innerhalb von einem halben Tag bis zwei Wochen von ein bis zwei Entwicklern umgesetzt werden kann.

Komplexe Stories dagegen sind häufig anzutreffen, wenn es um die Entwicklung von neuen Algorithmen oder die Erweiterung bestehender geht. Hier hat es sich bewährt, diese Story mit einer Recherche in Form eines Spikes zu ergänzen. Mit Hilfe der Recherchestory lässt sich dann die Durchführbarkeit ermitteln, neue Erkenntnisse über eine mögliche Implementierung gewinnen und somit erfolgt eine Vorarbeit zur eigentlichen Story, die nach der Recherche (besser) abgeschätzt werden kann. Es liegt auf der Hand, dass die Recherche nicht in der selben Iteration durchgeführt werden soll, in der auch die Umsetzung der Story eingeplant ist – idealerweise liegt der Spike in einer vorherigen Story.

Testbar

Die Akzeptanztests einer User Story definieren die Erwartungen an die Umsetzung. Erst anhand der Tests kann somit nachvollzogen werden, ob eine Story vollständig und erfolgreich implementiert wurde. Diese Tests sollten auch möglichst automatisiert ausgeführt werden – ein Automatisierungsgrad von 99% ist erstrebenswert. Lediglich sehr wenige Tests lassen sich nicht oder nicht mit verhältnismäßigem Aufwand automatisieren. Bei Anforderungen an die intuitive Bedienbarkeit, zum Beispiel, sind automatisierte Tests nicht möglich – mittels repräsentativer User-Tests in Testlaboren wäre solch eine Story jedoch durchaus testbar. Solche Tests sind dann aber oft zeitintensiv und kostspielig, für manche Projekte und Produkte jedoch notwendig.

In der Praxis entstehen nicht testbare Stories häufig bei den nicht-funktionalen Anforderungen, bei denen Erwartungen nur vage formuliert werden. Ein Beispiel dafür wäre “Das System hat geringe Antwortzeiten”. So formuliert kann diese Story nie erfüllt werden. Deutlich besser und sogar automatisiert testbar wäre dagegen folgende Formulierung: “Die visuelle Rückmeldung für alle Interaktionen eines Users mit dem System sind in 98% der Fälle unter einer Sekunde.”

Akronym

Diese sechs Eigenschaften ins englische Übersetzt ergeben ein Akronym:

  • Independent
  • Negotiable
  • Valueable
  • Estimable
  • Small
  • Testable

… INVEST.

Literatur:

[1] Mike Cohen, „User Stories Applied: For Agile Software Development“, Addison-Wesley Professional; 1 edition (11. März 2004)

[2] Alan Cooper, „The Origin Of Personas“, cooper.com Journal, http://www.cooper.com/journal/2008/05/the_origin_of_personas (15. Mai 2008)

[3] Jared M. Spool,„Three Important Benefits of Personas“, uie.com Articles, https://articles.uie.com/benefits_of_personas/ (8. Mai 2007)

Grafik: