Story-Zerlegung

Die Story-Zerlegung ist die Struktur, welche die Anforderungen an eine Lösung in abnehmendem Detailgrad beschreibt: oben die Lösungsziele, darunter die minimal vermarktbaren Funktionalitäten (minimal marketable features, MMF) oder Komponenten, darunter die Stories, darunter die Akzeptanzkriterien, die jede einzelne Story bestätigen. Die Agile Extension to the BABOK Guide führt jede Story durch diese Struktur, die zu gross oder zu wenig verstanden ist, um ausgearbeitet, geschätzt oder geliefert zu werden. Der Abstieg erfolgt schrittweise: Die erste Analyse setzt die Ziele, die MMF und die grossen Stories; der untere Teil des Baums füllt sich, während die Initiative fortschreitet. Der Guide legt auch die Grundlage der Aufteilung fest: die Funktionalität, die für den Kunden einen Wert hat.

Ziel

Die Agile Extension to the BABOK Guide gibt der Technik diesen Zweck: die Anforderungen an eine Lösung auf der passenden Detailstufe auszudrücken, ausgerichtet auf die angestrebten Ergebnisse. Ihr Erzeugnis ist eine Hierarchie mit vier Ebenen, vom Gesamtkontext bis zu den Akzeptanzkriterien einer Story, wobei jede Ebene an die darüberliegende gebunden bleibt.

Das Backlog Refinement ist die wiederkehrende Tätigkeit, die in einer Sitzung stattfindet und in der die Aufteilung vorgenommen wird, während die Story-Zerlegung die Struktur ist, der diese Aufteilung folgt. Die funktionale Dekomposition behandelt jeden beliebigen Gegenstand, eine Funktion, einen Prozess oder die zu leistende Arbeit, unter zwei Verträgen, die auf jeder Stufe geprüft werden: Die Kinder decken ihren Elternknoten ab; jeder Knoten hat nur einen Elternknoten. Ihre Tiefe ergibt sich aus der Aufgabe, die den Baum verbrauchen wird; jene der Story-Zerlegung ergibt sich aus dem Abstand zur Lieferung, unter einem Werttest, der Story für Story angewandt wird. Die beiden Bäume erreichen deshalb ungleiche Tiefen. Die Story-Ausarbeitung, in §7.19 der Agile Extension behandelt, fügt einer bereits bestehenden Story das Detail und die Kriterien hinzu: Die Zerlegung ändert die Zahl der Stories, die Ausarbeitung ändert, was eine Story sagt.

Die Tabelle 7.0.1 der Agile Extension ordnet sie dem Anforderungsmanagement und der Seite der internen Teams zu, ohne Eintrag für aussenstehende Stakeholder. Die Hierarchie dient zuerst denen, die bauen, denn sie ordnet eine Arbeit, bevor diese vorführbar ist.

Einsatz

Wann einsetzen

Story zu gross, um geschätzt oder geliefert zu werden: Der Guide macht dies zum Auslöser.
Start einer Initiative: die Lösungsziele und die MMF setzen, bevor eine Story im Detail entsteht.
Release-Planung: entscheiden, welche Funktionalitäten ausgeliefert werden, in welcher Reihenfolge und wie weit.
Team, das sich im Detail verliert: Die Hierarchie bindet jede Story an das Geschäftsziel, das sie rechtfertigt.
Abstimmung mit Schulung und Change Management: Die MMF geben den Zuschnitt vor, an dem sich diese Arbeiten ausrichten.
Backlog aus einer technischen Aufteilung geerbt: neu nach Funktionalitäten aufteilen, die der Kunde beurteilen kann.

Wann nicht einsetzen

Story bereits schätzbar und lieferbar: Sie ist reif für die Ausarbeitung.
Umfang, Prozess oder Organisation zu zerlegen: Diese Gegenstände gehören zur funktionalen Dekomposition.
Story nicht schätzbar, ohne dass die Grösse die Ursache wäre: Das Hindernis ist eine Unbekannte, und ein Spike beseitigt sie.

Beschreibung

Die vier Ebenen

Ebene	Was sie trägt	Was sie zu entscheiden erlaubt
Lösungsziele	Die oberste Ebene der Geschäftsanforderungen: die Beweggründe, aus denen die Initiative unternommen wird.	Der Massstab, an dem jeder detaillierte Bedarf beurteilt wird.
MMF / Komponente	Logische Gruppierungen von Funktionalitäten und Fähigkeiten, welche die Lösung bieten muss, damit sich eine Inbetriebnahme lohnt. Sie bilden oft die Themen eines Release.	Was in welchem Release ausgeliefert wird und der Gesamtkontext des Produkts.
Story	Eine User Story, eine Job Story, ein Anwendungsfall oder eine umzusetzende Anforderung.	Was ein Team in eine Iteration nimmt.
Akzeptanzkriterien	Die Zufriedenheitsbedingungen, die eine Story bestätigen, geschrieben als Listen, als Spezifikationen oder als Abnahmetests.	Unter welchen Bedingungen die Story angenommen wird.

Die zweite Ebene trägt im Guide selbst zwei Namen: §7.18 nennt sie MMF oder Komponente, während §6.7.1 auf dem Horizont Delivery decompose epics to stories schreibt. Wer aus SAFe oder aus einem Backlog-Werkzeug kommt, erkennt den Gegenstand unter dem Namen Epic. Die vierte Ebene entsteht bei der Story-Ausarbeitung, an der einen Story, deren Lieferung bevorsteht; die Zerlegung selbst hört auf, sobald die Story als Kandidatin vorliegt.

In die Breite zerlegen, bevor es in die Tiefe geht

Der Ansatz, den die Agile Extension breadth-before-depth nennt, Breite vor Tiefe, ordnet den Abstieg: zuerst die Geschäftsziele, dann die Komponenten, die je einen Zuwachs an Nutzen für den Kunden tragen, dann die Stories, dann deren Akzeptanzkriterien. Sind die MMF oder die Funktionsgruppen einmal festgelegt, können Anwendungsfälle an die Stelle der Stories treten.

Auf einer agilen Initiative erkennen die ersten Analysetätigkeiten die Ziele, die MMF und die meisten grossen Stories; die Aufteilung dieser Stories wird schrittweise abgeschlossen. Der Guide nennt den Grund: Diese Stories werden sich ändern und das Verständnis der Anforderungen wird sich weiterentwickeln, sodass ein frühes Absteigen bis zur letzten Ebene Arbeit erzeugt, die weggeworfen wird.

Die Grundlage der Aufteilung

Die Agile Extension schliesst drei Grundlagen der Aufteilung aus: den Prozess (Schritt 1, Schritt 2, Schritt 3 eines Ablaufs), die Architektur (zuerst die Datenbank bauen, dann den Server, dann die Oberfläche) und das Vorgehen (entwerfen, bauen, testen). Die gewählte Grundlage ist die Funktionalität, die für den Kunden einen Wert hat.

Zwei Kataloge aus der Praxis nennen die Muster für die Aufteilung, welche diese Vorgabe einhalten. Richard Lawrence und Peter Green führen neun auf: Schritte des Ablaufs, Varianten einer Geschäftsregel, Varianten der Daten, Erfassungs- oder Oberflächenvarianten, einfacher Fall gegen komplexen Fall, aufgeschobene Performance, Hauptaufwand, CRUD-Operationen (anlegen, lesen, ändern, löschen), Spike. Mike Cohn behält fünf unter dem Akronym SPIDR: Spike, Pfad, Oberfläche, Daten, Regeln. Der Spike steht in beiden Katalogen: Einen herauszulösen macht die verbleibende Story kleiner. Das ist die Aufteilung, die zu wählen ist, wenn die Unbekannte jede Aufteilung nach dem Wert verhindert. Wann die Aufteilung aufhören darf, sagen die INVEST-Kriterien von Bill Wake. Zwei davon geben hier den Ausschlag: valuable, die Story bringt etwas, das der Kunde beurteilen kann; independent, sie wird geliefert, ohne auf die anderen zu warten.

Was eine Zerlegung scheitern lässt

Die Rückkehr zur detaillierten Spezifikation im Voraus

Der Guide benennt dieses Anti-Pattern: die Story-Zerlegung als Weg zurück zur detaillierten Spezifikation im Voraus zu behandeln. Der Baum steigt dann überall bis zu den Akzeptanzkriterien ab. Heraus kommt eine vollständige Spezifikation unter einem anderen Namen. Das Gegenmittel liegt im just-enough, just-in-time: zu wissen, wann mit dem Zerlegen aufzuhören ist, Ast für Ast, je nach dem Abstand zwischen jedem MMF und seiner Lieferung.

Die technische Aufgabe im Gewand einer Story

"Die Abonnementstabelle anlegen" hat die Form einer Story und den Gehalt einer Aufgabe. Kein Kunde kann sie abnehmen, keine Vorführung zeigt sie und ein Release aus solchen Teilen liefert nichts Brauchbares, solange das letzte nicht fertig ist. Wenn im Review niemand ausserhalb des Teams sagen kann, ob die Sache funktioniert, ist die Aufteilung der Architektur gefolgt.

Die Hierarchie, die ihre Spitze verliert

Zwei der Stärken, die der Guide ihr zuschreibt: die Ziele des Projekts präsent zu halten und jede Funktionalität, ob verlangt oder gebaut, bis zu den Geschäftszielen zurückzuverfolgen. Beide gehen verloren, wenn die Stories im Werkzeug flach angelegt werden, ohne Elternknoten. Das Backlog wird weiterhin gefüllt; wozu eine Story dient, lässt sich nicht mehr klären, und die Entscheidung fällt zugunsten der lautesten Stimme.

KI-Überlegungen

Ein Sprachmodell verkürzt die mechanische Arbeit der Aufteilung. Eine grosse Story zusammen mit dem Katalog der Muster einzureichen und zu jedem vorgeschlagenen Schnitt das angewandte Muster zu verlangen, ergibt eine Liste von Kandidaten, die das Team sichtet. Dasselbe Modell gleicht eine bereits geschriebene Story mit den INVEST-Kriterien ab und meldet jene, die keinen Nutzen nennen, das Anzeichen einer technischen Aufteilung. Es hilft auch, eine Liste von Funktionalitäten zu MMF-Kandidaten zu gruppieren, die der Product Owner annimmt oder neu fasst.

Die Aufteilung, die ein Modell von sich aus vorschlägt, übernimmt die in seinen Trainingsdaten häufigsten Achsen, die technisch sind: eine Datenschicht, eine Oberfläche, eine Stapelverarbeitung. Genau diese Grundlage schliesst §7.18 aus. Das Modell muss die Vorgabe des Kundennutzens deshalb in der Anweisung erhalten, und die Ausgabe wird auf diesen Punkt hin gelesen statt auf ihre Form, die selten zu beanstanden ist. Die Reihenfolge der MMF bleibt eine Entscheidung des Product Owners: Sie fällt aufgrund von Erträgen, vertraglichen Fristen und regulatorischen Auflagen, die ein Modell nicht kennt.

Ein Backlog enthält Kundennamen, Auszüge aus Störungsmeldungen und Vertragsdetails. Dieses Material geht nicht an einen externen Dienst, ohne dass die Nutzung abgedeckt ist; das Bundesgesetz über den Datenschutz (DSG) gilt für einen Auszug aus dem Backlog wie für alles andere.

Beispiele

Ein Schweizer Telekommunikationsanbieter zerlegt das Kundenportal, das er seinen Mobilfunkkunden öffnen will. Hier der Stand des Baums zu dem Zeitpunkt, zu dem das Team seine nächste Iteration plant.

Ebene	Inhalt
Lösungsziele	Der Kunde verwaltet sein Mobilfunkabonnement, ohne den Kundendienst anzurufen.
MMF / Komponente	Abonnementswechsel · Roaming-Optionen (noch nicht zerlegt)
Stories unter "Abonnementswechsel"	Als Kunde möchte ich mein aktuelles Abonnement und meinen Datenverbrauch des Monats sehen, um zu beurteilen, ob ich das Abonnement wechseln soll. 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. Als Kunde möchte ich noch am selben Tag zu einem teureren Abonnement wechseln, um sofort über die Daten zu verfügen, die mir fehlen. Als Kunde mit subventioniertem Gerät möchte ich die Abonnementsstufe sehen, die mein Vertrag bis zu seinem Ablauf vorschreibt, um zu wissen, wie weit ich heruntergehen kann.
Akzeptanzkriterien der Story "zu einem günstigeren Abonnement wechseln"	Das neue Abonnement gilt ab dem ersten Tag des folgenden Abrechnungszyklus. Der Kunde sieht den neuen Monatspreis, CHF 29 gegenüber CHF 39 für das laufende Abonnement, in einer Bestätigung, die er freigibt. Ein bereits für den Zyklus vorgemerkter Wechsel sperrt einen zweiten, bis er wirksam wird.

Nur ein Ast reicht bis zu den Akzeptanzkriterien hinunter, jener, dessen Lieferung nahe ist.

Diese vier Stories stammen aus einer einzigen, die zu gross ins Refinement kam: "Als Kunde möchte ich mein Abonnement im Kundenportal wechseln, um das zu bezahlen, was ich verbrauche." Zwei Muster teilen sie auf. Die Schritte des Ablaufs lösen die Übersicht heraus: das eigene Abonnement und den Verbrauch des Monats zu sehen ist eine Handlung, die für sich steht und dem Kunden bereits bei der Entscheidung dient. Die Varianten der Geschäftsregel trennen danach drei Fälle: Eine Herabstufung wird zum nächsten Abrechnungszyklus wirksam, eine Höherstufung noch am selben Tag und ein Abonnement, das mit einem subventionierten Gerät abgeschlossen wurde, geht vor Ablauf des Vertrags nicht unter seine Stufe. Die Herabstufung geht in die Iteration; die Übersicht, die Höherstufung und der Fall des subventionierten Geräts bleiben Story-Kandidaten unter demselben MMF. Jede besteht die Prüfung nach INVEST: Sie wird geliefert, ohne auf die anderen zu warten, und sie ändert etwas, das der Kunde beurteilen kann.

"Roaming-Optionen" bleibt auf der Ebene des MMF, solange die Lieferung nicht nahe ist, und die Akzeptanzkriterien werden nur für die Story geschrieben, die das Team in die Iteration nimmt. Der Kunde, der herabstuft, spart CHF 10 pro Monat, also CHF 120 über zwölf Monate; für den Anbieter ist derselbe Betrag ein entgangener Abonnementsertrag. Was die Story rechtfertigt, ist das Ziel an der Spitze des Baums: ein Abonnementswechsel ohne Anruf beim Kundendienst.

Visualisierungen

Die Technik wird als vier übereinanderliegende Reihen gezeichnet, von oben nach unten verbunden. Die oberste Reihe, jene der Lösungsziele, trägt einen einzigen Kasten. Die zweite trägt die MMF, die dritte die Stories, die vierte die Akzeptanzkriterien der einen Story, deren Lieferung nahe ist. Die Zahl der Äste ist von Knoten zu Knoten ungleich, denn die Aufteilung folgt dem Wert.

Die Zeichnung macht die ungleiche Tiefe der Äste sichtbar: Ein Ast nahe der Lieferung reicht bis zu den Akzeptanzkriterien hinunter, während sein Nachbar beim MMF endet. Ein Baum, dessen Äste alle zur selben Zeit die vierte Ebene erreichen, zeigt die Rückkehr zur detaillierten Spezifikation im Voraus.

Aufwand

Phase	Stufe	Begründung
Vorbereitung	Gering	Die Lösungsziele kommen aus der Vision und dem Business Case; die Technik nimmt sie auf und öffnet den Baum.
Durchführung	Mittel	Ein erster Durchgang im Workshop für die Ziele und die MMF, danach eine Aufteilung, die bei jedem Backlog Refinement über die ganze Initiative hinweg wiederkehrt.
Dokumentation	Gering	Die Hierarchie lebt im Backlog-Werkzeug, als Verknüpfung zwischen Eltern- und Kindknoten; kein separates Dokument zu führen.

Werkzeuge

Das Backlog-Werkzeug trägt die Hierarchie: Jira verbindet Epic und Story, Azure DevOps fügt dazwischen eine Ebene Feature ein, GitLab stapelt Epics und Issues. Keines bietet genau die vier Ebenen des Guides, sodass die Zuordnung einmal entschieden und in den Konventionen des Teams festgehalten wird. Andernfalls ordnen zwei Teams denselben Gegenstand auf zwei Ebenen ein und die konsolidierten Sichten werden falsch.

Die Wand oder das geteilte Board (Miro, Mural oder Haftnotizen an einer Wand) eignet sich für den ersten Durchgang in die Breite, jenen mit dem ganzen Team. Eine Karte von einer Ebene auf die andere zu verschieben ist dort ein Ziehen und Ablegen, eine gesuchte Eigenschaft, solange die Gruppierung in MMF nicht stabil ist; der Inhalt geht danach ins Werkzeug hinunter.

Der Katalog der Muster für die Aufteilung, auf eine Karte gedruckt und auf den Tisch der Refinement-Sitzung gelegt, macht aus "diese Story ist zu gross" eine benannte Aufteilung. Die neun Muster von Lawrence und Green wie auch die fünf von SPIDR passen auf eine Seite, und ein Team, das sie vor Augen hat, schlägt Aufteilungen nach dem Wert vor.

Quellen

IIBA, Agile Extension to the BABOK Guide, §7.18 Story Decomposition: der Zweck der Technik, der Auslöser einer Story, die zu gross oder zu wenig verstanden ist, der Ansatz breadth-before-depth und sein schrittweiser Charakter, die vier Elemente Lösungsziele, MMF oder Komponente, Story und Akzeptanzkriterien sowie die genannten Stärken und Grenzen, darunter die Rückverfolgbarkeit zu den Geschäftszielen, die Unterstützung der Release-Planung, das Anti-Pattern der Rückkehr zur detaillierten Spezifikation im Voraus und der Ausschluss einer Aufteilung nach Prozess, Architektur oder Vorgehen.
IIBA, Agile Extension to the BABOK Guide, §7.0, Tabelle 7.0.1 Selecting the Right Technique: die Technik eingeordnet unter den Techniken des Anforderungsmanagements, auf der Seite der internen Teams.
Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003: der Ursprung der sechs INVEST-Kriterien, von denen valuable und independent darüber entscheiden, wann eine Aufteilung aufhören darf.
Richard Lawrence und Peter Green, The Humanizing Work Guide to Splitting User Stories, Humanizing Work: Katalog aus der Praxis, nicht normativ; die neun Muster für die Aufteilung einer Story.
Mike Cohn, SPIDR: Five Simple but Powerful Ways to Split User Stories, Mountain Goat Software: Katalog aus der Praxis, nicht normativ; die fünf Muster des Akronyms SPIDR.