Story-Ausarbeitung

Ziel

Die Story-Ausarbeitung legt den Entwurf im Detail und die Akzeptanzkriterien einer Story fest, so weit es die Lieferung einer funktionierenden Lösung verlangt. Sie behandelt jeweils eine einzige Story. Die Agile Extension zum BABOK Guide macht sie zur untersten Stufe der Zerlegung.

Die Story-Zerlegung entscheidet, wie viele Stories es gibt und wo jede in der Hierarchie steht. Die Ausarbeitung nimmt eine bereits richtig zugeschnittene Story und füllt sie. Ausgearbeitet wird meist eine User Story, mitunter ein Anwendungsfall oder eine detaillierte Anforderung im Backlog.

§7.19.2 ordnet die Technik dem Horizont Delivery zu. Die Tabelle 7.0.1 reiht sie unter das Anforderungsmanagement ein, auf der Seite der internen Teams.

Einsatz

Wann einsetzen

• Story für die kommende Iteration ausgewählt: sie in den Tagen vor dem Planungsworkshop ausarbeiten.
• Akzeptanzkriterien fehlen oder sind nicht prüfbar: die Sitzung schreibt sie in eine Form um, die der Tester ausführen kann.
• Absicht des Kunden ist mehrdeutig: Beispiele mit Zahlen entscheiden, was eine abstrakte Formulierung offenlässt.
• Geschäftsregel zu bestätigen: der Experte, der sie kennt, antwortet in der Sitzung.
• Detail vor Monaten geschrieben: die Sitzung erneut ansetzen, statt einem Text zu trauen, den das Release überholt hat.

Wann nicht einsetzen

• Story zu gross für eine Iteration: sie an die Story-Zerlegung zurückgeben, bevor Detail hinzukommt.
• Story, die erst in mehreren Iterationen ausgeliefert wird: bis dahin genügt das Backlog Refinement.
• Technische Unbekannte, die jede Antwort blockiert: ein Spike beseitigt sie, bevor die Sitzung überhaupt Material hat.

Beschreibung

Wer im Raum sitzt

Die Agile Extension nennt vier Rollen: die Fachexperten, welche die Regel kennen, den Kundenvertreter, der die Story braucht, die Person, die sie testen wird, und den Business Analysten, der die Sitzung moderiert und die Story auf die Probe stellt. Die ersten drei bringen die drei Blickwinkel ein, unter denen sich eine Story als unvollständig erweist: die Regel, die Absicht, die Prüfbarkeit. Three Amigos, ein Begriff von George Dinwiddie, den die Agile Alliance aufgegriffen hat, bezeichnet die Prüfung eines Arbeitsgegenstands unter den Perspektiven Fachbereich, Entwicklung und Test. Der Guide führt in seiner Liste keinen Entwickler: §7.19 deckt zwei dieser Perspektiven ab, den Fachbereich und den Test, und der Business Analyst nimmt darin den Platz des Entwicklers ein. In der Praxis schreibt eine Sitzung, aus der niemand zum Bauen hinausgeht, Kriterien, ohne dass irgendjemand darin beziffert, was sie kosten werden.

Der Business Analyst hat dort zwei Rollen. Moderieren heisst, das Thema bei einer Story zu halten und die Sitzung abzubrechen, wenn die Antwort fehlt. Hinterfragen heisst, für jedes Kriterium zu fragen, wie es geprüft wird und auf welchen Daten. Die Agile Extension besteht darauf: Der Praktiker arbeitet bewegliche Anforderungen laufend aus und vermittelt sie, was ebenso viel Moderation wie Kommunikation verlangt.

Gerade rechtzeitig, gerade genug

Die Ausarbeitung betrifft nur die Stories, die für die kommende Iteration ausgewählt sind. Sie findet zur Vorbereitung des Planungsworkshops statt, früh genug, damit das Team auf geschriebenem Detail schätzt. Der praktische Richtwert ist eine Iteration Vorlauf.

Der Guide nennt zwei Fehler im Zeitpunkt. Zu früh: Die Information altert, das Release entwickelt sich um sie herum und das Detail muss vor dem Gebrauch erneut erhoben werden. Zu spät: Das Team wartet oder beginnt mit einer Story, deren Kriterien nicht geschrieben sind, und die Frage wird dann im Code entschieden.

Der Guide schreibt der Technik drei Stärken gut: weniger Zeit für die Elizitation und weniger Dokumentation, kein Detail für eine Funktionalität, die sich vor der Umsetzung ändern wird, ein Team, das bei der am höchsten priorisierten Funktionalität des Backlogs bleibt.

Die Akzeptanzkriterien

Die Ausarbeitung klärt Akzeptanzkriterien, fügt neue hinzu oder streicht bestehende. Format und Aufbau dieser Messgrössen gehören zu den Akzeptanz- und Bewertungskriterien. Klären: Ein als Absicht geschriebenes Kriterium erhält einen Wert, eine Schwelle oder ein Datum. Hinzufügen: Eine Frage des Fachexperten fördert einen Fall zutage, den niemand abgedeckt hatte. Entfernen: Ein Kriterium beschreibt eine andere Story oder schreibt eine technische Lösung vor, die das Team weiterhin frei wählen darf.

Jedes Kriterium muss sich durch einen Test entscheiden lassen, den der Tester schreiben kann, bevor die Umsetzung beginnt. Die Form Angenommen, Wenn, Dann, die das Behaviour Driven Development verbreitet hat, zwingt dazu, den Ausgangszustand, die Aktion und das beobachtbare Ergebnis zu benennen. Ron Jeffries nannte den Grund dafür 2001, als er die Confirmation neben die Karte und das Gespräch stellte: Was mündlich vereinbart wird, geht verloren, ausser in Form eines Tests, den jemand laufen lassen kann.

Was die Sitzung hervorbringen kann

Der Guide zählt fünf mögliche Ergebnisse auf. Jedes beantwortet eine offen gebliebene Frage.

Der Guide gibt sie als optional an. Alle fünf für jede Story zu erzeugen, ist das Zeichen dafür, dass der Workshop die detaillierte Spezifikation im Voraus wieder aufgenommen hat, die das agile Vorgehen beiseitelässt.

Was der Workshop hinterlässt

Das Ergebnis ist ein gemeinsames Verständnis unter den Stakeholdern darüber, was geliefert werden muss, damit die Story den Zustand "Done" erreicht. Die Kriterien, die Szenarien, das Mockup und die Datentabelle sind die schriftlichen Spuren dieses Gesprächs. Sie hängen an der Story im Backlog-Werkzeug, wo Umsetzung und Test sie wiederfinden. Ein separates Protokoll ist schon bei der ersten Änderung eines Kriteriums nicht mehr auf demselben Stand.

Was eine Ausarbeitung scheitern lässt

Die Story, die an die Zerlegung zurückgehört

Die Sitzung stellt fest, dass eine Story nicht in eine Iteration passt. Der Guide sieht diesen Fall vor: Die Ausarbeitung erkennt Gelegenheiten zur Zerlegung. Richtig ist, die Story an die Zerlegung zurückzugeben und die Teile auszuarbeiten, wenn sie ihrerseits ausgewählt werden. Der übliche Fehler ist weiterzumachen und dann zwei Stunden Detail an einer Story zu erzeugen, die in der Woche darauf aufgeteilt wird.

Der falsch eingeschätzte Detailgrad

Der Guide erkennt die Schwierigkeit an, ohne sie zu lösen: den Grad zu finden, der es erlaubt, zu entwickeln, zu testen und mit den Kriterien zu vergleichen. Zu wenig Detail: Das Team erfindet die Regel während der Umsetzung. Zu viel Detail: Das Team folgt einem Entwurf, den Leute festgelegt haben, die nicht umsetzen werden. Man hört auf, wenn der Tester seinen Test schreiben kann und die Umsetzung kein zweites Gespräch mehr braucht, um zu beginnen.

Die Sitzung ohne Tester

Der Tester ist der Einzige, dessen Beruf darin besteht, zu fragen, woran man es erkennen wird. Fehlt er, werden die Kriterien als plausible Absichten geschrieben und die Frage der Prüfung stellt sich am Ende der Iteration, wenn die Antwort eine Nacharbeit kostet. Er ist die Person, die am häufigsten dem Terminplan geopfert wird, weil sie erst später an die Reihe zu kommen scheint.

KI-Überlegungen

Ein Sprachmodell arbeitet gut an der Form der Sitzungsergebnisse. Aus einer Story und ihren Kriterien schlägt es Szenarien nach dem Muster Angenommen, Wenn, Dann vor und zählt die Fälle auf, die ein Raum unter Zeitdruck vergisst: den Grenzwert, die leere Liste, das doppelte Absenden, den Abbruch mitten im Vorgang. Es wandelt auch einen Satz von Kriterien in das Gerüst einer Tabelle der Ein- und Ausgabedaten um, das die Sitzung korrigiert, statt es selbst zu erstellen.

Die Ausarbeitung steht unter dem gerade genug, und ein Modell erzeugt dreissig Szenarien zum selben Preis wie sechs. Eine erzeugte Liste, die unverändert an die Story gehängt wird, bricht das gerade genug: Das Team wird seine Iteration damit verbringen, Fälle zu erfüllen, die niemand verlangt hat. Die brauchbare Anweisung setzt eine Obergrenze und lässt jedes Szenario durch ein Kriterium begründen.

Die Geschäftsregel entzieht sich dem Modell. Dass ein subventioniertes Gerät verbietet, vor Ablauf des Vertrags unter eine bestimmte Abonnementsstufe zu wechseln, ist eine vertragliche Tatsache, die der Experte für die Fakturierung kennt. Ein danach befragtes Modell erzeugt eine plausible Regel, die sich der Form nach nicht von einer richtigen unterscheiden lässt. Mockups und Datentabellen tragen Feldnamen und Beispieldatensätze, die oft aus echten Daten stammen; das Bundesgesetz über den Datenschutz (DSG) gilt für diesen Auszug wie für den Rest.

Beispiele

Ein Schweizer Telekommunikationsanbieter arbeitet die für die nächste Iteration ausgewählte Story aus: "Als Kunde möchte ich ab dem nächsten Abrechnungszyklus zu einem günstigeren Abonnement wechseln, um nicht länger für Daten zu bezahlen, die ich nicht nutze." Sie kommt mit drei Akzeptanzkriterien aus der Zerlegung. Aus der Sitzung geht sie mit vier Szenarien, einem Mockup und einer Datentabelle hervor.

Das vierte Szenario ist dasjenige, das die Zerlegung nicht gesehen hatte. Der Experte für die Fakturierung fragt, was mit dem laufenden Zyklus geschieht, und die Sitzung legt die Regel fest: Es wird nichts zurückerstattet. Bei einem Zyklus von 30 Tagen bleiben nach einer Bestätigung am 20. April 10 Tage zum alten Tarif. Eine anteilige Verrechnung hätte von der monatlichen Differenz von CHF 10 den Anteil dieser 10 Tage gutgeschrieben, also CHF 10 × 10 ÷ 30 = CHF 3.33, auf den Rappen gerundet. Dieser Betrag wird nicht gutgeschrieben: Die Aprilrechnung bleibt bei CHF 39.00 und der Tarif von CHF 29.00 läuft ab dem 1. Mai. Die Zahl dient hier dazu, zu messen, was die Regel ausschliesst.

Das Mockup mit geringem Detailgrad für den Bestätigungsbildschirm besteht aus vier Zeilen und einer Schaltfläche: aktuelles Abonnement CHF 39.00, neues Abonnement CHF 29.00, monatliche Ersparnis CHF 10.00, wirksam ab dem 1. Mai. Die Tabelle der Ein- und Ausgabedaten legt den Vertrag des Dienstes fest.

Visualisierungen

Die Technik lässt sich als zwei Panels zeichnen. Links die Story, wie sie aus der Zerlegung kommt: eine Karte mit ihrem einzigen Satz. Rechts dieselbe Story nach der Sitzung, umgeben von den Elementen, die der Workshop an sie gehängt hat, den Akzeptanzkriterien, den Szenarien, dem Mockup und der Tabelle der Ein- und Ausgabedaten. Ein gestrichelter Pfeil verlässt das zweite Panel, beschriftet mit dem einzigen Fall, der sich nicht im Raum klären lässt: die zu grosse Story, die an die Zerlegung zurückgeht.

Die Zeichnung trägt die Invariante der Technik: Die Story behält ihre Identität von einem Panel zum anderen, nur ihr Detail wächst. Ein rechtes Panel mit mehreren Karten statt einer einzigen würde die Zerlegung zeichnen.

Aufwand

Werkzeuge

Das Werkzeug zur Backlog-Verwaltung nimmt die Ergebnisse der Sitzung auf: ein Feld für Akzeptanzkriterien an der Story, Unteraufgaben für die Aufteilung, Anhänge für das Mockup. Kriterien, die in einem Kommentar oder in einem verknüpften Dokument abgelegt sind, entgehen den Teamansichten und der Definition of Done.

Das gemeinsame Board, Miro, Mural oder eine Wand und Haftnotizen, trägt die Sitzung: Die Beispiele werden verschoben, gruppiert und weggeworfen. Dieses Medium eignet sich für die Skizze eines Datenmodells oder eines Flusses, welche die Sitzung zur Klärung einer Frage zeichnet und danach fallen lässt.

Das Werkzeug für Mockups mit geringem Detailgrad, Balsamiq oder Figma im Wireframe-Modus, erfüllt die Rolle, die der Guide vorsieht. Ein zu fertig wirkendes Mockup verlagert das Gespräch auf Farben und Abstände, während die Sitzung die Felder und die Regeln sucht.

Das Werkzeug für ausführbare Szenarien, Cucumber, SpecFlow oder ein gleichwertiges, verlängert die Sitzung, wenn das Team Behaviour Driven Development betreibt: Die im Workshop geschriebenen Szenarien werden zu Tests, die laufen. Ein Team, das sie nicht ausführt, behält dieselbe Schreibvorlage ohne die Werkzeuge.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.19 Story Elaboration: der Gegenstand der Technik, ihr Platz im Horizont Delivery, die Durchführung als Workshop und die Liste der Rollen, die Disziplin des gerade rechtzeitig und des gerade genug, die Vorbereitung des Planungsworkshops, die Elemente: die Elizitation, die Rückgabe an die Zerlegung, die Akzeptanzkriterien und die fünf optionalen Ergebnisse, dazu die genannten Stärken und Grenzen, darunter die beiden Fehler im Zeitpunkt und die Schwierigkeit, den Detailgrad zu beurteilen.
• IIBA, Agile Extension to the BABOK Guide, §7.0, Tabelle 7.0.1 Selecting the Right Technique: die Technik eingereiht unter den Techniken des Anforderungsmanagements, auf der Seite der internen Teams.
• Ron Jeffries, Essential XP: Card, Conversation, Confirmation, XProgramming, 2001: die Confirmation als dritter Bestandteil einer Story, älter als die Technik, die sie erhellt, ohne sie zu definieren.
• Agile Alliance, What are the Three Amigos?: die drei Perspektiven Fachbereich, Entwicklung und Test, zusammengeführt an einem Arbeitsgegenstand, George Dinwiddie zugeschrieben.