Aufteilung von User Stories, die nicht in einen Sprint passen

Das Aufteilen einer User Story bedeutet, eine zu umfangreiche Story in kleinere Stories zu zerlegen, von denen jede für sich genommen bereits einen für den Nutzer nutzbaren Mehrwert bietet. Eine Story, die Sie nicht einschätzen können, ist in der Regel eine, die Sie noch nicht ausliefern können, und durch das Aufteilen bringen Sie sie wieder auf den Plan.

Die meisten Gespräche, in denen es heißt „Das können wir nicht einschätzen“, sind in Wirklichkeit versteckte Aufteilungsgespräche. Das Team hat kein Problem mit Zahlen und Aufwand; es hat ein Problem mit zu vielen Unbekannten. Durch die Aufteilung werden die Unbekannten reduziert, bis die Story die Form einer bereits erledigten Aufgabe annimmt und sich die Schätzungen annähern.

Wann man mit dem Schätzen aufhören und mit dem Aufteilen beginnen sollte

Eine Story, die nicht in einen Sprint passt, ist kein Problem der Größe, sondern ein Problem der Form. Achten Sie auf folgende Anzeichen:

• Das Team gibt Stimmen in den 13er- und 20er-Bereichen ab und stimmt dann immer wieder neu ab, um zu einer Einigung zu gelangen, anstatt sich zu spalten.
• „Das kommt darauf an“ ist die Antwort auf mehr als nur einige der Vertiefungsfragen.
• Die Geschichte erstreckt sich über den Zuständigkeitsbereich mehrerer Teams.
• „Erledigt“ erfordert mehrere Bereitstellungen.
• Sie können dies in zwei Sätzen beschreiben, jedoch nicht in zwei Akzeptanzkriterien.

Wenn Sie dennoch darauf bestehen, verbringt das Team den Sprint damit, es zu versuchen, und überträgt die verbleibenden Aufgaben in den nächsten Sprint (was schlecht ist, da es sich dabei um die schwierigsten Aufgaben handelt) oder stellt eine lieferbare Teilmenge fertig und erklärt das Projekt für abgeschlossen, während der Rest unvollendet bleibt. Beides ist schlechter, als die Aufgaben bewusst vor Beginn des Sprints aufzuteilen.

Warum ein großer Stimmenunterschied eine Pattsituation bedeutet und keine Neuwahl

Wenn ein Team bei der Arbeit mit Planning Poker zusammenarbeitet, ist eine große Streuung das aussagekräftigste Signal, das dabei entsteht. Karten, die von 3 bis 13 reichen, deuten nicht auf eine Uneinigkeit hinsichtlich der Zahlen hin. Es handelt sich vielmehr um zwei Geschichten, die so tun, als wären sie eine. Derjenige, der eine 3 vergibt, sieht einen bestimmten Umfang; derjenige, der eine 13 vergibt, sieht einen anderen Umfang. Eine erneute Abstimmung wird diese Ansichten nicht in Einklang bringen; die eigentliche Aufgabe besteht darin, im Gespräch zu klären, welcher Umfang zutreffend ist. Folgendes spielt dabei in der Regel im Hintergrund eine Rolle:

• Eine Person ermittelt die Anforderungen für den „Happy Path“, eine andere für die Randfälle.
• Der eine geht davon aus, dass das Design bereits existiert; der andere geht davon aus, dass er es entwirft.
• Eine Person befasst sich mit der Dimensionierung der Abfrage; eine andere mit der Dimensionierung der Einführung.
• Eine Person weiß, dass diese Abhängigkeit besteht; eine andere weiß es nicht.
• Eine Person führt eine Bedarfsermittlung für jemanden im Raum durch; die Aufgabe fällt in den Zuständigkeitsbereich eines anderen Teams.

Mehr Details beheben dieses Problem selten: Sie führen zu einem längeren Ticket, nicht zu einer präziseren Schätzung. Eine Aufteilung hingegen schon: in einen „Spike“, wenn die Unbekannte die Ursache ist, in vertikale Abschnitte, wenn die Unbekannte der Umfang ist. Zwei ausgebreitete Karten bedeuten nicht, dass sich das Team uneinig ist. Es bedeutet, dass das Team über verschiedene Stories abstimmt. Schicken Sie es zurück.

Schneiden Sie vertikal, nicht horizontal.

Die Aufteilung muss vertikal erfolgen, nicht horizontal: ein schmaler Ausschnitt, der tatsächlich eigenständig ausgeliefert werden kann. „Backend zuerst, Frontend im nächsten Sprint“ teilt die Story so, wie ein Messer Teig teilt: Man erhält zwei Hälften von nichts. Ein vertikaler Ausschnitt berührt jede Schicht und liefert eine funktionsfähige Spalte – einen Button, der durchgängig funktioniert, auch wenn er nur einen einzigen Eingabefall verarbeitet. Das vollständige Prinzip finden Sie unter horizontale vs. vertikale Aufteilung.

Erfolgreiche Aufteilungsmuster

SPIDR (Spike, Pfad, Schnittstelle, Daten, Regeln) deckt die meisten Aufteilungsszenarien ab und ist daher der erste Ansatzpunkt. Einige weitere Muster treten häufig genug auf, um eine Nennung zu rechtfertigen.

Workflow-Schritte

Eine Story, die eine gesamte Benutzerreise umfasst (Registrierung, Einstellungen vornehmen, E-Mail bestätigen, Dashboard aufrufen), lässt sich oft klar entlang der Schrittgrenzen unterteilen. Wenn dies funktioniert, ist es die übersichtlichste Technik im Werkzeugkasten: Jede Story liefert ein erkennbares, für den Benutzer sichtbares Ergebnis, jede lässt sich demonstrieren, und jede kann für sich allein im Umfang definiert werden.

Der Test besteht aus einer einzigen Frage, die bei jedem Schritt gestellt wird: Würde der Nutzer davon profitieren, wenn wir nur diese Funktion und sonst nichts veröffentlichen würden? „Einstellungen festlegen“ besteht den Test: Ein Nutzer mit festgelegten Einstellungen, aber ohne E-Mail-Bestätigung, befindet sich weiterhin in einem nutzbaren Zustand. „Formular absenden“ besteht den Test nicht: Ein Benutzer, dessen Absendung ins Leere läuft, ist schlechter dran als zuvor. Lautet die Antwort „Nein“, handelt es sich bei dem Schritt um eine Teilaufgabe, nicht um eine Story, und der Arbeitsablauf wird an dieser Stelle nicht aufgeteilt.

Die schnellere Variante desselben Tests: Könnte jeder Schritt innerhalb von drei Sprints in die Produktion übergehen, ohne dass sich sonst etwas ändert, und dabei an jeder Station ein stimmiges Erlebnis hinterlassen? Wenn das Überspringen eines Schritts dazu führt, dass der Nutzer eine fehlerhafte Seite vorfindet, ist die Aufteilung unecht. Das ist die Falle, in die Entwicklungsteams tappen: Die Schritte entsprechen der Gliederung des Codes (Authentifizierungsdienst, Einstellungen-API, Dashboard-Komponente), sodass sie detailliert wirken. Sie sind detailliert. Sie sind zudem horizontale Schnitte mit einem Workflow-Vokabular darüber, und keiner von ihnen liefert dem Nutzer tatsächlich etwas aus. Das verrät es: Jeder „Schritt“ liegt in der Verantwortung genau eines Spezialisten. Echte Workflow-Schritte erstrecken sich über den gesamten Stack hinweg, denn echte, benutzerseitige Schritte tun dies ebenfalls.

Varianten von Geschäftsregeln

Eine Story mit mehreren Regeln oder Rollen (normaler Benutzer, Administrator, API-Client) wird nach Regeln unterteilt. Stellen Sie die häufigste Regel zuerst bereit; die Varianten folgen danach. Jede Variante ist eine eigenständige Story mit eigenen Benutzern.

Erfolgsszenario, anschließend Fehlerszenario

Eng verwandt mit dem Path-Ansatz von SPIDR. Stellen Sie zunächst den „Happy Path“ bereit; Fehlerbehandlung, Wiederholungsversuche und Randfälle folgen anschließend. Der Benutzer kann bereits Erfolg haben, noch bevor die Fehlerfälle vollständig behandelt sind, solange Sie in der Zwischenzeit ein schlechteres Fehlerverhalten in Kauf nehmen und später tatsächlich darauf zurückkommen.

Aufgeschobene Qualität

Veröffentlichen Sie den Release ohne die Feinarbeit (keine Tooltips, keine Animationen, keine Admin-Überschreibungen) und veröffentlichen Sie die Feinarbeit dann als eigenständiges Feature. Dies funktioniert nur, wenn Sie die Feinarbeit tatsächlich veröffentlichen. Teams, die die Qualität vernachlässigen und nie darauf zurückkommen, bleiben am Ende mit unvollständigen Funktionen zurück.

Betrieb

Eine Geschichte, die teils eine Benutzerfunktion, teils ein betriebliches Anliegen (Protokollierung, Überwachung, Alarmierung) ist, lässt sich entlang dieser Linie aufteilen. Stellen Sie zunächst den benutzerseitigen Teil bereit; der betriebliche Teil folgt als Nacharbeit, die oft schneller vonstattengeht, da die Funktion bereits in Produktion ist und die Lücken sichtbar sind.

Was ist keine echte Trennung?

„In diesem Sprint das Frontend, im nächsten das Backend“ ist keine Aufteilung; es ist eine Verschiebung der Auslieferung, da keine der beiden Hälften für sich allein ausgeliefert wird. „Erst entwickeln, dann die Tests schreiben“ folgt dem gleichen Prinzip: Ungetesteter Code ist ein Risiko, kein Teilbereich. Wenn ein Arbeitsschritt erst dann einen Wert hat, wenn sein Gegenstück fertiggestellt ist, haben Sie die Story nicht aufgeteilt. Sie haben sie lediglich terminiert.

Wenn sich ein Artikel nicht aufteilen lässt: Führen Sie einen Spike durch

Manchmal ist das Unbekannte der Umfang selbst: Niemand hat dies zuvor getan, die API des Anbieters liefert keine Antwort auf die entscheidende Frage zur Belastbarkeit, oder die Arbeit hängt von einer Kennzahl ab, über die noch niemand verfügt (aktueller p99-Wert, aktuelles Aufrufvolumen, aktuelle Datenstruktur). In solchen Fällen führen Sie einen „Spike“ durch: eine zeitlich begrenzte Untersuchung, deren Ergebnis Wissen ist (ein Dokument, ein Prototyp, eine Empfehlung, ein Messwert) und nicht auslieferbarer Produktcode. Danach sind Sie in der Lage, den tatsächlichen Aufwand ehrlich einzuschätzen.

Spikes werden oft missbräuchlich als „Fangen wir einfach an und schauen, was passiert“ verwendet. Das ist kein Spike, sondern eine nicht geschätzte Story mit zusätzlichen Schritten. Zwei Anzeichen dafür, dass Sie das falsche Werkzeug verwenden: Es wird keine konkrete Frage beantwortet, oder das Ergebnis lautet „die Funktion ist fertiggestellt“. Ersteres bedeutet, dass das Team sich eigentlich nicht unsicher ist; Letzteres bedeutet, dass es sich um eine Story handelt.

Sollte eine einzelne Phase immer noch nicht ausreichen, ist das Projekt noch nicht fertig; es handelt sich um ein Projekt. Planen Sie es als solches, kommunizieren Sie den Zeitplan und hören Sie auf, so zu tun, als würde ein Sprint dafür ausreichen.

Häufig gestellte Fragen

Wie teilt man eine User Story auf?

Teilen Sie das Ganze vertikal nach den Ergebnissen für den Benutzer auf, sodass jeder Abschnitt jede Ebene berührt und etwas liefert, das ein Benutzer nutzen kann – selbst wenn damit nur ein einziger Fall abgedeckt wird. SPIDR bietet fünf zuverlässige Trennlinien: Spike, Pfad, Schnittstelle, Daten, Regeln. Wählen Sie diejenige aus, die einen Abschnitt ergibt, den Sie tatsächlich veröffentlichen würden.

Was tun Sie, wenn eine User Story zu umfangreich für einen Sprint ist?

Teilen Sie es bewusst auf, bevor der Sprint beginnt. Eine Story, die nicht passt, wird entweder schlecht übertragen (der Rest ist dann das, was am schwierigsten war) oder als unvollständig fertiggestellte Teilmenge ausgeliefert. Beides ist schlechter als eine bewusste vertikale Aufteilung in Abschnitte, die jeweils für sich allein ausgeliefert werden.

Wann sollten Sie eine Story aufteilen, anstatt sie zu schätzen?

Wenn das Team die Aufgabe nicht in einen Sprint unterbringen kann, wenn die Bewertungen weit auseinanderliegen (eine 3 neben einer 13), wenn mehr als nur ein paar Fragen zur Präzisierung mit „Das kommt darauf an“ beantwortet werden oder wenn die Story mehr als ein Team betrifft. Eine große Streuung ist kein Meinungsunterschied hinsichtlich der Wertung; es handelt sich vielmehr um zwei Stories, die so tun, als wären sie eine.

Was versteht man unter einem „Spike“ in der agilen Entwicklung?

Ein Spike ist eine zeitlich begrenzte Untersuchung, die durchgeführt wird, wenn das Team den Umfang einer Story nicht einschätzen kann, ohne zunächst weitere Informationen einzuholen. Das Ergebnis ist Wissen (ein Dokument, ein Prototyp, eine Messung) und kein Produktcode, der ausgeliefert wird. Zwei Dinge unterscheiden einen Spike von einer zeitlich unbegrenzten Arbeit: eine zeitliche Begrenzung und ein zu lieferndes Ergebnis.

Was sind die gängigen Methoden, um eine User Story aufzuteilen?

Workflow-Schritte, Varianten von Geschäftsregeln, „Happy Path“ und „Unhappy Path“, aufgeschobene Qualitätssicherung sowie betriebliche Belange – dazu die fünf SPIDR-Schnittpunkte. Der Test für all diese Aspekte ist derselbe: Würde der Nutzer davon profitieren, wenn nur dieser Teil ausgeliefert würde und nichts anderes?

Weiterführende Literatur

• Agile Schätzung: Der umfassende Leitfaden ist die zentrale Anlaufstelle für alle Informationen zu diesem Thema.
• SPIDR-Story-Splitting behandelt die fünf zuverlässigen Trennlinien ausführlich.
• Horizontales vs. vertikales Aufteilen ist das Prinzip, das jeder guten Aufteilung zugrunde liegt.
• Definition von „ready“ ist die Hürde, die ein Split-Story nehmen muss, bevor er wieder in den Sprint aufgenommen wird.
• Backlog-Verfeinerung ist der Prozess, in dessen Rahmen die Aufteilung tatsächlich erfolgt.