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, lässt sich in der Regel noch nicht ausliefern – 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 lassen sich die Unbekannten reduzieren, bis die Story die Form einer bereits erledigten Aufgabe annimmt – und die Schätzungen sich annähern.

Wann man mit dem Schätzen aufhören und mit der Aufteilung 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 stimmt zunächst mit 13 und 20 Stimmen ab und führt anschließend weitere Abstimmungen durch, 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.
• „Fertig“ 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 auf den nächsten Sprint – was schlecht ist, da dabei genau die schwierigsten Aufgaben übrig bleiben – oder es 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 mit Planning Poker arbeitet, 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 Stories, die als eine einzige ausgegeben werden. Derjenige, der eine 3 vergibt, sieht einen bestimmten Umfang; derjenige, der eine 13 vergibt, sieht einen anderen Umfang. Eine erneute Abstimmung wird diese Sichtweisen nicht in Einklang bringen – die eigentliche Aufgabe besteht darin, im Gespräch zu klären, welcher Umfang der richtige ist. Folgendes spielt dabei in der Regel im Hintergrund eine Rolle:

• Eine Person ermittelt die Anforderungen für den Normalfall, eine andere für die Randfälle.
• Der eine geht davon aus, dass der Entwurf bereits existiert; der andere geht davon aus, dass er ihn 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 Karten nebeneinander 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 – ein schmaler Ausschnitt, der tatsächlich eigenständig ausgeliefert werden kann – und nicht horizontal. „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 – eine Schaltfläche, die von Anfang bis Ende funktioniert, auch wenn sie nur einen Eingabefall verarbeitet. Das vollständige Prinzip finden Sie unter horizontale vs. vertikale Aufteilung.

Erfolgreiche Aufteilungsmuster

SPIDR – Spike, Path, Interface, Data, Rules – deckt die meisten Aufteilungsszenarien ab und ist daher der erste Anhaltspunkt, den Sie prüfen sollten. Einige weitere Muster treten häufig genug auf, um eine Erwähnung zu verdienen.

Workflow-Schritte

Eine Story, die eine gesamte Benutzerreise umfasst – Registrierung, Einstellungen vornehmen, E-Mail bestätigen, Dashboard anzeigen – lässt sich oft klar an den Schrittgrenzen unterteilen. Wenn dies funktioniert, ist es die übersichtlichste Technik im Werkzeugkasten: Jede Story liefert ein erkennbares, für den Benutzer sichtbares Ergebnis, jede kann vorgeführt werden, und der Umfang jeder einzelnen lässt sich eigenständig festlegen.

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“ scheitert – ein Nutzer, 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 schlüssiges Nutzererlebnis 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 Aufgliederung des Codes (Authentifizierungsdienst, Einstellungen-API, Dashboard-Komponente), sodass sie detailliert erscheinen. Sie sind detailliert. Sie sind zudem horizontale Schnitte, die mit Workflow-Begriffen überlagert sind, 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, 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 aufgeteilt. Stellen Sie zunächst die häufigste Regel bereit; die Varianten folgen danach. Jede Variante ist eine eigenständige Story mit ihren eigenen Benutzern.

Erfolgsszenario, dann Fehlerszenario

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

Aufgeschobene Qualität

Veröffentlichen Sie die Version zunächst ohne den letzten Schliff – ohne Tooltips, ohne Animationen, ohne Administrator-Überschreibungen – und veröffentlichen Sie den letzten Schliff dann als eigenständiges Feature. Dies funktioniert nur, wenn Sie den letzten Schliff 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 Teil. 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 eine Meldung nicht aufteilen lässt: Veröffentlichen Sie einen Kurzbericht

Manchmal ist das Unbekannte der Umfang selbst – noch hat dies niemand zuvor getan, die API des Anbieters liefert keine Antwort auf die entscheidende Frage zur Belastbarkeit, oder die Arbeit hängt von einer Messgröße 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, eine Messgröße – und nicht auslieferbarer Produktcode. Anschließend sind Sie in der Lage, den tatsächlichen Umfang ehrlich einzuschätzen.

Spikes werden fälschlicherweise als „Fangen wir einfach an und schauen wir mal, was passiert“ missbraucht. Das ist kein Spike – es ist 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 implementiert“. Ersteres bedeutet, dass das Team eigentlich nicht unsicher ist; Letzteres bedeutet, dass es sich um eine Story handelt.

Sollte auch ein einzelner Abschnitt noch nicht ausreichen, ist die Geschichte noch nicht fertig – es handelt sich um ein Projekt. Behandeln Sie es als solches, legen Sie den Zeitplan fest 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 auf – entlang der Nutzerergebnisse, sodass jeder Ausschnitt jede Ebene berührt und etwas liefert, das ein Nutzer nutzen kann, selbst wenn es nur einen einzigen Fall abdeckt. SPIDR bietet fünf zuverlässige Trennlinien: Spike, Pfad, Schnittstelle, Daten, Regeln. Wählen Sie diejenige aus, die einen Ausschnitt 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 in den nächsten Sprint übertragen – wobei der übrig gebliebene Teil genau das ist, was am schwierigsten war – oder als halbfertige 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 bewerten?

Wenn das Team die Aufgabe nicht in einen Sprint einplanen kann, wenn die Abstimmungsergebnisse weit auseinanderliegen (eine 3 neben einer 13), wenn auf mehr als nur ein paar Präzisierungsfragen mit „Das kommt darauf an“ geantwortet wird oder wenn die Story mehr als ein Team betrifft. Eine große Streuung ist kein Meinungsunterschied hinsichtlich der Punktzahl – 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 weitere Informationen einzuholen. Das Ergebnis ist Wissen – ein Dokument, ein Prototyp, eine Messung – und kein Produktcode, der ausgeliefert wird. Zwei Dinge zeichnen einen „Spike“ im Gegensatz zu einer zeitlich unbegrenzten Arbeit aus: eine zeitliche Begrenzung und ein zu lieferndes Ergebnis.

Welche gängigen Methoden gibt es, 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 Maßstab für all diese Aspekte ist derselbe: Würde der Nutzer davon profitieren, wenn nur dieser Teil ausgeliefert würde und sonst nichts?

Weiterführende Literatur

• Agile Schätzung: Der umfassende Leitfaden – hier finden Sie alles zum Thema.
• SPIDR-Story-Aufteilung – die fünf zuverlässigen Trennlinien im Detail.
• Horizontales vs. vertikales Aufteilen – das Prinzip, das jeder guten Aufteilung zugrunde liegt.
• Definition von „ready“ – die Hürde, die ein Split-Story nehmen muss, bevor er wieder in den Sprint aufgenommen wird.
• Backlog-Verfeinerung – der Prozess, in dessen Rahmen die Aufteilung tatsächlich erfolgt.