Aufteilung von User Stories, die nicht in einen Sprint passen

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

Die meisten Gespräche, in denen es heißt „Das können wir nicht einschätzen“, sind in Wirklichkeit verschleierte 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 der Aufteilung beginnen sollte

Eine Story, die nicht in einen Sprint passt, ist kein Problem der Umfangsbestimmung, sondern ein Problem der Struktur. 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 ungünstig 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, sind kein zahlenmäßiger Dissens. Es handelt sich um zwei unterschiedliche Sichtweisen, die vorgeben, eine einzige zu sein. Der Teilnehmer mit der 3 sieht einen Umfang; der Teilnehmer mit der 13 sieht einen anderen Umfang. Eine erneute Abstimmung wird diese Sichtweisen nicht in Einklang bringen; die eigentliche Aufgabe besteht in der Diskussion darüber, welcher Umfang der richtige 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 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 Größenbestimmung für jemanden im Raum durch; die Arbeit 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 – eine Schaltfläche, die durchgängig 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 rechtfertigen.

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“ besteht den Test nicht: 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 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 Aufgliederung des Codes (Authentifizierungsdienst, Einstellungen-API, Dashboard-Komponente), sodass sie detailliert erscheinen. Sie sind detailliert. Es handelt sich jedoch auch um horizontale Schnitte, die mit Workflow-Begriffen überlagert sind, und keiner von ihnen liefert dem Nutzer tatsächlich etwas aus. Das Erkennungsmerkmal: 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 (normale Benutzer, Administrator, API-Client) wird nach Regeln aufgeteilt. Stellen Sie zunächst die häufigste Regel bereit; die Varianten folgen anschließend. Jede Variante ist eine eigenständige Story mit ihren 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 Teil ohne die Feinarbeit (keine Tooltips, keine Animationen, keine Administrator-Überschreibungen) und veröffentlichen Sie die Feinarbeit anschließend 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 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 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 Messgröße ab, über die noch niemand verfügt (aktueller p99-Wert, aktuelles Anrufaufkommen, 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 Messung) und nicht auslieferbarer Produktcode. Anschließend sind Sie in der Lage, den tatsächlichen Aufwand ehrlich einzuschätzen.

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

Sollte auch eine einzelne Phase 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 Nutzerergebnissen auf, sodass jeder Ausschnitt jede Ebene berührt und etwas liefert, das ein Nutzer 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 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 hineinpasst, wird entweder schlecht in den nächsten Sprint übertragen (wobei der übrig gebliebene Teil genau das ist, 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 einplanen kann, wenn die Abstimmungsergebnisse stark auseinandergehen (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 Wertung; es handelt sich vielmehr um zwei Stories, die vorgeben, eine einzige zu sein.

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 auslieferbarer Produktcode. Zwei Faktoren unterscheiden einen Spike von einer zeitlich unbegrenzten Arbeit: eine zeitliche Begrenzung und ein zu erbringendes Ergebnis.

Welche gängigen Methoden gibt es, um eine User Story aufzuteilen?

Workflow-Schritte, Varianten von Geschäftsregeln, der „Happy Path“ und der „Unhappy Path“, aufgeschobene Qualitätssicherung sowie betriebliche Belange, dazu die fünf SPIDR-Schnitte. Der Test 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“ ist die zentrale Anlaufstelle für alle diesbezüglichen Informationen.
• Der Artikel über die SPIDR-Story-Splitting-Methode behandelt die fünf zuverlässigen Trennlinien ausführlich.
• Das Prinzip des horizontalen gegenüber dem vertikalen Aufteilens ist die Grundlage jeder gelungenen Aufteilung.
• Die Definition von „ready“ bezeichnet die Hürde, die ein Split-Story überwinden muss, bevor es wieder in den Sprint aufgenommen wird.
• Die Backlog-Verfeinerung ist der Prozess, in dessen Rahmen die Aufteilung tatsächlich erfolgt.