User Stories
Eine User Story ist eine kurze Aussage über ein Bedürfnis, das einem bestimmten Stakeholder Wert bringt: wer das Bedürfnis hat, was er tun möchte und warum es zählt, in ein bis zwei Sätzen. Sie sagt bewusst nicht alles, denn sie ist ein Platzhalter für ein Gespräch, ergänzt durch Akzeptanzkriterien, während sich das Team der Lieferung nähert. Der BABOK stellt sie als eine Option der Anforderungsdarstellung dar; die Agile Extension gibt ihr ihre agile Mechanik, ihr Leben auf einem Backlog, die INVEST-Heuristik und das Drei-C-Modell.
Ziel
Eine User Story erfasst ein Bedürfnis auf einer leichten Granularität und lädt dazu ein, es im Gespräch zu erkunden, statt es in einer Spezifikation festzuschreiben. Die Karte passt in einen Satz, weil sie nicht alles tragen soll: sie benennt einen Stakeholder, was er tun möchte und den Wert, den er daraus zieht, und sie überlässt das Detail dem Gespräch, das kommt, wenn sich das Team der Lieferung nähert.
Fast die gesamte Steuerung einer iterativen Lieferung ordnet sich um diese winzige Einheit. Die Story ist die Einheit der Priorisierung, abgelegt auf einem Backlog, das der Product Owner ordnet, und die Einheit, die das Team für die Schätzung dimensioniert. Ihre Akzeptanzkriterien werden zu den Abnahmetestfällen. Sie misst den gelieferten Wert, verfolgt die Anforderungen, die sie abdeckt, und trägt das Fortschrittsreporting. Das Ergebnis ist die Story selbst, die Karte und ihre Akzeptanzkriterien, die auf dem Backlog leben, denn ihr Wert liegt in dem Gespräch, das sie auslöst und das ein starres Dokument ersticken würde.
Die beiden Leitfäden rahmen sie nicht gleich. Der BABOK behandelt die Story als statisches Artefakt der Anforderungsdarstellung, als leichtgewichtiges Mittel der Dokumentation, und warnt, dass sie der kurzfristigen Erfassung dient, nicht der langfristigen Wissensbewahrung und auch keiner Governance-Referenzbasis. Die Agile Extension behandelt sie dynamisch, als Platzhalter für ein Gespräch, das auf einem Backlog lebt, und sie liefert die beiden Heuristiken, die der BABOK nicht hat: die Qualität, mit INVEST, und die Struktur, mit den drei C. Man nimmt das erste für die Definition und den dokumentarischen Rahmen, das zweite für die agile Mechanik.
Einsatz
Wann einsetzen
- Iterative, inkrementelle Lieferung: der Wert wird in Scheiben geliefert und die Prioritäten verschieben sich von Iteration zu Iteration.
- Ein Bedürfnis erfassen, ohne es festzuschreiben: den Stakeholder und seinen Wert einfangen und dann das Gespräch öffnen, statt eine Spezifikation einzufrieren.
- Eine Grundlage für Schätzung und Planung: die Story ist die Einheit, die das Team dimensioniert und die auf dem Backlog geordnet wird.
- Abnahmetests zu verankern: die Akzeptanzkriterien der Story sind ihr direkter Ausgangspunkt.
- Gelieferten Wert messen und Anforderungen verfolgen: die Story ist die Einheit, die das Bedürfnis mit dem Gelieferten und dem Fortschrittsbericht verbindet.
Wann nicht einsetzen
- Regulatorische oder sicherheitskritische Anforderungen: der Satz und sein Gespräch hinterlassen keine dauerhafte, rückverfolgbare Spur, eine vollständige Anforderungsspezifikation schreiben.
- Verhalten mit vielen alternativen Pfaden und Ausnahmen: eine Zeile trägt die Abläufe nicht, zu den Use Cases greifen.
- Festpreis-Auftrag ohne laufenden Zugang zu den Stakeholdern: das versprochene Gespräch wird nicht stattfinden, den Umfang vertraglich festlegen, statt sich darauf zu verlassen.
Beschreibung
Der Satz und seine Elemente
Die Form, die jeder kennt, «als Rolle möchte ich Ziel, damit Nutzen», gehört keinem der beiden Leitfäden. Es ist die sogenannte Connextra-Vorlage, popularisiert von Mike Cohn in User Stories Applied, und die Leitfäden geben sie nur weiter. Ihre Kraft kommt aus ihrem dritten Teil: dem damit, das den Nutzen benennt. Die ersten beiden Teile sagen wer und was, und eine klassische Anforderung würde dort haltmachen; es ist der Nutzen, der aus der Aussage eine Story macht und der später erlaubt, zwischen zwei Wegen zu ihrer Erfüllung abzuwägen.
Der BABOK benennt vier Elemente. Den Titel, optional, ein Tätigkeitsverb, das die Story zusammenfasst. Die Wertaussage, den Kern, mit dem Wer, dem Was und dem Warum. Das Gespräch, die Diskussion über das Bedürfnis zwischen den Stakeholdern und dem Team. Und die Akzeptanzkriterien, die festlegen, was geprüft wird. Der BABOK listet sie auf; die Agile Extension setzt sie in einem Modell in Beziehung, das erklärt, warum eine Karte mit einem Satz genügt.
Die drei C: die Story ist ein Token
Das Drei-C-Modell geht auf Ron Jeffries zurück, der es im Kontext des Extreme Programming formuliert hat. Es hält in drei Wörtern, die im Englischen alle mit C beginnen. Die Card (Karte) ist das Token: gerade genug Text, um die Anforderung zu erkennen und zu behalten. Jeffries gibt den Test, der die Storys klein hält: wenn das Bedürfnis nicht auf die Karte passt, ist die Karte zu gross. Die Conversation (das Gespräch) ist der Ort, an dem die Anforderung tatsächlich übertragen wird, über die Zeit, zwischen den Stakeholdern und dem liefernden Team; die Karte sagt bewusst nicht alles. Die Confirmation (die Bestätigung) sind die Akzeptanzkriterien, die Grundlage für Abnahme-, Regressions- und explorative Tests, die bestätigen, dass das gelieferte Element das Bedürfnis erfüllt.
INVEST: die Qualität einer Story prüfen
INVEST ist das Akronym von Bill Wake, veröffentlicht 2003, und es ist das Werkzeug, mit dem man beurteilt, ob eine Story nutzbar ist, bevor man sie übernimmt. Jeder Buchstabe ist eine Eigenschaft, die die Story halten muss. Eine Story, die an einer davon scheitert, ist keine gute Story, wie gut sie auch geschrieben ist.
| Kriterium | Was es prüft |
|---|---|
| Independent (unabhängig) | Die Story lässt sich für sich allein liefern, ohne von der Reihenfolge einer anderen abzuhängen, was dem Product Owner die Freiheit lässt, sie zu priorisieren. |
| Negotiable (verhandelbar) | Die Karte ist eine Einladung zum Gespräch: das Detail wird im Gespräch geklärt. |
| Valuable (wertvoll) | Sie bringt einem benannten Stakeholder spürbaren Wert. Es ist das «damit», das sie trägt. |
| Estimable (schätzbar) | Das Team kann sie dimensionieren. Eine Story, die sich nicht schätzen lässt, ist zu vage oder zu gross. |
| Small (klein) | Sie passt in eine Iteration. Die Agile Extension formuliert dieses «S» als Sized Appropriately um; die Anforderung bleibt dieselbe. |
| Testable (testbar) | Ihre Akzeptanzkriterien erlauben es, objektiv zu entscheiden, ob sie erfüllt ist. |
Die Technik durchführen
- Den Stakeholder und das Bedürfnis bestimmen
Die Story gehört jemandem, und dieser Jemand kommt aus der Erhebung: aus einem Workshop, einem Interview, einer Beobachtung vor Ort. Die Personas helfen hier unmittelbar, denn die Rolle am Kopf der Karte ist oft eine Persona, und das Bedürfnis eines Neuankömmlings ist nicht das eines langjährigen Kunden. - Die Karte schreiben
In der Form wer, was, warum, in ein bis zwei Sätzen, mit einem optionalen Titel mit Tätigkeitsverb. Man hält die Karte bewusst kurz, denn ihre Kürze ist es, die das Gespräch erzwingt. - Sie auf das Backlog legen
Der Product Owner priorisiert sie gegen die anderen. Das Backlog ist eine geordnete Warteschlange, die sich bei jeder Iteration neu ordnet: bei jedem Durchgang stuft der Product Owner das Verbliebene neu ein, gemessen am erwarteten Wert und an dem, was die letzte Lieferung gelehrt hat, sodass eine vor einem Monat geschriebene Story an die Spitze steigen oder ans Ende fallen kann, ohne je neu geschrieben zu werden. - Das Gespräch führen
Wenn die Lieferung näher rückt, wird die Story mit dem Team ausgearbeitet. Dort fügt man hinzu, was die Umsetzung braucht und was die Karte nicht hätte tragen sollen: ein Datenmodell, Geschäftsregeln, einen Bildschirmentwurf, ein Zustandsdiagramm. - Die Akzeptanzkriterien festlegen
Die Confirmation, oft in der Form «angenommen, wenn, dann» geschrieben. Sie werden zugleich mit der Karte festgelegt: sie sagen, was die Story wirklich bedeutet, und sie sind es, was sie testbar macht. - INVEST prüfen und bei Bedarf zerlegen
Eine zu grosse oder nicht unabhängige Story wird in kleinere Storys geschnitten. Die Story-Zerlegung ist die für dieses Zerschneiden vorgesehene Technik; die Sitzung zum Story Mapping bestimmt, welche Storys dorthin gehen. - Laufend verfeinern
Die Backlog-Verfeinerung ist wiederkehrende Arbeit: die Storys klären sich, werden neu geschnitten und neu priorisiert, während das Team lernt.
Was eine Story scheitern lässt
Die als Aufgabe geschriebene Story
«Als Entwickler möchte ich das Zahlungsmodul refaktorieren» ist verkleidete technische Arbeit, ohne Stakeholder und ohne Wert. Eine Story benennt einen Nutzniesser und einen Nutzen.
Die für eine Iteration zu grosse Story
Sie verletzt Small und Estimable und muss zerlegt werden.
Das fehlende «damit»
Die Agile Extension benennt diese Falle: das Team konzentriert sich auf die Funktion und lässt den Nutzen fallen. Der Nutzen ist der Daseinsgrund der Story.
Die Akzeptanzkriterien als nachträglicher Gedanke
Die Confirmation ist integraler Bestandteil; ohne sie gibt es nichts, wogegen validiert werden kann.
Die Karte für eine vollständige Spezifikation gehalten
Man vergisst die Conversation, und das Token beginnt, die Vollständigkeit zu beanspruchen, die es nie hatte.
Das anschwellende Backlog
Die Zerlegung vervielfacht die Storys, und ohne Verfeinerung verrottet das Backlog unter seinem eigenen Gewicht.
Die aus den Augen verlorene Vision
Vor lauter Blick auf jede Story hört man auf, das Produkt zu betrachten; die Roadmap ist es, die den Kurs über den Karten hält.
KI-Überlegungen
Ein Modell hilft bei der Formgebung. Man gibt ihm ein Interviewtranskript, eine Funktionsnotiz oder ein Workshop-Protokoll, und man erhält eine erste Karte in der Form wer, was, warum, mit einem Vorschlag für Akzeptanzkriterien in «angenommen, wenn, dann». Das ist ein Ausgangspunkt, mit dem man streiten kann, und er erspart den Start bei null. Ein Modell leistet drei weitere konkrete Dienste. Es schlägt eine Zerlegung einer zu grossen Story in kleinere Kandidaten vor, die das Team bestätigt oder verwirft. Es prüft einen Stapel Storys anhand von INVEST, um mechanisch das fehlende «damit», die als Aufgabe geschriebene Story oder die Aussage zu melden, die niemand wird schätzen können. Und es gleicht die Karten auf Französisch, Deutsch und Englisch ab für ein Team, das in den drei Sprachen des Landes arbeitet.
Die Grenzen sind hart und sie folgen daraus, was eine Story ist. Die Priorisierung ist eine Geschäftsentscheidung: Wert und Häufigkeit sind Eigenschaften dieser Organisation und ihrer Kundschaft, ein Modell hat keinen Zugang dazu, und zur Entscheidung gezwungen wird es eine plausible und falsche Reihenfolge erzeugen. Das Gespräch lässt sich nicht automatisieren: die Anforderung wird zwischen Menschen übertragen, und eine maschinengeschriebene Karte, die das Gespräch kurzschliesst, stellt genau die Falle wieder her, die die Technik vermeiden soll, die für eine Spezifikation gehaltene Karte. Akzeptanzkriterien, die Geld oder Compliance verpflichten, werden mit dem Fachbereich überprüft: ein Modell erfindet eine Schwelle, einen CHF-Betrag oder eine Frist, die richtig aussieht und keiner Regel des Hauses entspricht. Schliesslich tragen Interviewtranskripte und Backlogs Personendaten, und sie gehen nicht in ein öffentliches Modell.
Beispiele
Eine Physiotherapiepraxis in der Westschweiz führt die Online-Terminbuchung ein. Das Bedürfnis eines Patienten wird zu einer Story, deren Karte mit ihren Akzeptanzkriterien das eigentliche Ergebnis ist.
Was die Karte zeigt und eine Zeile Spezifikation verbergen würde, ist das «damit». «Einen Termin online buchen» ist eine Funktion; «damit ich nicht während der Öffnungszeiten anrufen muss» ist der Grund, der sie zur Priorität macht und der später sagen wird, ob eine andere Lösung es genauso gut täte. Ohne diese Hälfte bleibt eine Aufgabe, ohne Stakeholder und ohne Wert.
Die beiden Akzeptanzkriterien sind die Confirmation, in der Form «angenommen, wenn, dann» geschrieben. Sie sagen, was «gebucht» wirklich bedeutet, sie werden zu den Testfällen und sie sind das Einzige auf der Karte, das sich objektiv prüfen lässt. Der Rest ist ein Platzhalter für das Gespräch, in dem das Detail geklärt wird, welche Stornofrist, welche Erinnerung, welche Sprache für die E-Mail. Gemessen an INVEST hält die Story: unabhängig von der Zahlung, die eine andere Story ist, wertvoll für den benannten Patienten, klein genug für eine Iteration und testbar durch ihre beiden Kriterien.
Visualisierungen
Die Technik erzeugt ein Artefakt, die Story-Karte. Es sind beschriftete, im Raum angeordnete Blöcke, die Wertaussage oben und das Band der Akzeptanzkriterien unten, was eine Zeichnung besser wiedergibt als eine Liste. Das Drei-C-Modell liest sich auf dieselbe Weise, als drei verbundene Felder, die den Übergang vom Token zum Gespräch und dann zum Nachweis tragen, und auch es wird gezeichnet. INVEST hingegen besteht aus Zeilen und Spalten, eine je Kriterium, und was aus Zeilen und Spalten besteht, wird als Tabelle wiedergegeben.
Kosten
| Phase | Niveau | Begründung |
|---|---|---|
| Vorbereitung | Gering | Die Story setzt einen identifizierten Stakeholder und ein Backlog voraus, das sie aufnimmt, mehr nicht. Die schwere Arbeit ist die vorgelagerte Erhebung, die das Bedürfnis zutage fördert; die Story selbst verlangt keine Installation, keine zu sammelnden Daten, keine Lizenz. |
| Durchführung | Mittel | Die Karte zu schreiben dauert wenige Minuten, doch ihre eigentlichen Kosten sind das Gespräch und die Akzeptanzkriterien, die sich für jede Story und jede Iteration wiederholen, samt der laufenden Backlog-Verfeinerung. |
| Dokumentation | Gering | Die Karte ist bewusst minimal und kurzfristig, es gibt also wenig festzuhalten. Das ist zugleich ihre Grenze: Wissen, das überdauern muss, ist anderswo zu schreiben. |
Werkzeuge
Die minimale Ausrüstung ist die Karteikarte, mit einer Wand, um das Backlog zu halten. Die physische Beschränkung der Karte ist hier eine Tugend: was nicht darauf passt, ist zu gross, und Karten an einer Wand umzuordnen ist genau die Priorisierung. Das Whiteboard und die Haftnotizen nehmen in einem am selben Ort arbeitenden Team denselben Platz ein.
Die Tabellenkalkulation genügt, um ein kleines Backlog zu halten, eine Zeile je Story, mit ihrer Priorität, ihrer Schätzung und ihren Kriterien. Die Werkzeuge zur Backlog-Verwaltung (Jira, Azure DevOps, GitLab, Trello und ihresgleichen) übernehmen, sobald die Story mit ihrer Schätzung, ihren Akzeptanzkriterien, ihren Aufgaben und den Anforderungen, die sie verfolgt, verbunden werden muss, und sobald das Team verteilt ist: das ist es, was das Backlog die Distanz überstehen lässt, wo die Wand nicht mehr mithält.
Die Werkzeuge der Spezifikation durch Beispiele (Cucumber, SpecFlow und ihresgleichen) verlängern die Confirmation: sie führen die in «angenommen, wenn, dann» geschriebenen Akzeptanzkriterien als automatisierte Tests aus, was die Schleife zwischen der Story und ihrer Prüfung schliesst. Dennoch ist kein Werkzeug erforderlich. Eine Karte an einer Wand, mit zwei auf der Rückseite geschriebenen Akzeptanzkriterien, ist eine vollständige Instanz der Technik.
Quellen
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.48 User Stories: die Definition, die Liste der Verwendungen, die vier Elemente (Titel, Wertaussage, Gespräch, Akzeptanzkriterien) und die genannte Grenze, eine kurzfristige Erfassung, die weder langfristige Wissensbewahrung noch eine Governance-Basis wert ist.
- IIBA, Agile Extension to the BABOK Guide, §7.21 User Stories: die vollständige agile Behandlung, das Leben der Story auf einem Backlog, das Drei-C-Modell, die Umformulierung des «S» von INVEST in Sized Appropriately, die Verwaltungsbeziehungen der Story und die Fallen des verlorenen «damit», des anschwellenden Backlogs und der vergessenen Vision.
- Mike Cohn, User Stories Applied for Agile Software Development, Addison-Wesley, 2004: die Connextra-Vorlage wer, was, warum und der Rahmen des Product Backlog; die Autorität hinter der normativen Form der Story.
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation, 2001: das Drei-C-Modell und der Test, der die Storys klein hält, «wenn das Bedürfnis nicht auf die Karte passt, ist die Karte zu gross».
- Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003: die INVEST-Heuristik, die sechs Eigenschaften einer nutzbaren Story, unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar.