Horizontale vs. vertikale Aufteilung

Bei der vertikalen Aufteilung wird eine Story nach den Ergebnissen für den Nutzer unterteilt; bei der horizontalen Aufteilung erfolgt die Unterteilung nach technischen Schichten. Diese eine Entscheidung bestimmt, ob jeder Teil etwas oder gar nichts liefert. Vertikale Teile liefern einen Mehrwert. Horizontale Teile liefern Versprechen.

Das horizontale Schneiden funktioniert so, wie ein Messer Teig teilt – man erhält zwei Hälften von nichts.

Der Unterschied

Bei der horizontalen Aufteilung erfolgt die Arbeit nach architektonischen Schichten: Frontend in diesem Sprint, Backend im nächsten, Datenbank im darauffolgenden Sprint. Die Arbeit lässt sich zwar in Sprints einteilen, doch in keinem einzelnen Sprint entsteht etwas, das die Nutzer konkret nutzen können. Die Velocity-Werte des Teams steigen; das für die Nutzer sichtbare Änderungsprotokoll bleibt jedoch leer.

Beim vertikalen Slicing erfolgt die Aufteilung anhand der Nutzerergebnisse. Ein schmaler Ausschnitt, der jede Ebene berührt – eine einzelne Schaltfläche, die tatsächlich durchgängig funktioniert, auch wenn sie nur einen einzigen Eingabefall abdeckt. Das Team liefert pro Ausschnitt weniger aus, doch jeder Ausschnitt ist ein echtes, lieferbares Produkt. Das Änderungsprotokoll füllt sich, die Nutzer sehen Fortschritte, und das Team kann den Kurs auf der Grundlage der tatsächlichen Nutzung statt der prognostizierten Nutzung anpassen.

Wenn eine horizontale Aufteilung erforderlich erscheint

Das ist in der Regel nicht der Fall. „Wir benötigen das Datenbankschema, bevor wir die Benutzeroberfläche erstellen können“, lautet die klassische Begründung, und fast immer weicht diese der Einstellung: „Wir können die Antwort fest einprogrammieren, die Benutzeroberfläche veröffentlichen und die Datenbank im nächsten Abschnitt erstellen.“ Das Unbehagen, ein vorläufiges Backend auszuliefern, ist durchaus real – aber es ist geringer als das Unbehagen, drei Sprints lang gar nichts auszuliefern.

Die Ausnahme: grundlegende Plattformarbeit

Manche Infrastrukturmaßnahmen verfügen bis zur Fertigstellung über keinen für die Nutzer sichtbaren Teil – beispielsweise die Migration zu einem neuen Authentifizierungsanbieter, der Austausch eines Warteschlangen-Backends oder die Erneuerung der Bereitstellungs-Pipeline. Dabei handelt es sich um Projekte, nicht um Stories. Behandeln Sie sie entsprechend: Teilen Sie sie nicht horizontal auf und tun Sie nicht so, als ob. Dimensionieren Sie sie als Projekt, kommunizieren Sie den Zeitplan und akzeptieren Sie, dass sich der Aufwand in der Velocity des Teams widerspiegeln wird. Eine Migration über drei Sprints als drei „Stories“ auszugeben, täuscht lediglich das Burndown-Diagramm.

Wenn ein Slice nichts enthält, was ein Benutzer nutzen kann, ist es kein Slice.

Häufig gestellte Fragen

Was versteht man unter „Vertical Slicing“ im agilen Entwicklungsansatz?

Beim vertikalen Slicing wird eine Story nach den Ergebnissen für den Benutzer aufgeteilt, sodass jeder „Slice“ einen schmalen Querschnitt durch alle Ebenen – Benutzeroberfläche, Logik und Daten – darstellt, der dem Benutzer etwas liefert, das er tatsächlich nutzen kann, auch wenn er nur einen einzigen Fall abdeckt. Jeder „Slice“ kann für sich allein veröffentlicht werden.

Was ist der Unterschied zwischen horizontalem und vertikalem Slicing?

Bei der horizontalen Aufteilung erfolgt die Unterteilung nach technischen Schichten – im einen Sprint das Frontend, im nächsten das Backend –, sodass in keinem einzelnen Sprint etwas entsteht, das ein Nutzer tatsächlich nutzen kann. Bei der vertikalen Aufteilung erfolgt die Unterteilung nach Nutzerergebnissen, sodass jeder Abschnitt einen funktionsfähigen End-to-End-Pfad liefert. Vertikale Abschnitte liefern einen Mehrwert; horizontale Abschnitte liefern Versprechen.

Warum ist vertikales Slicing besser?

Denn jedes Segment ist ein echtes, lieferbares Ergebnis. Das Changelog füllt sich, die Nutzer sehen Fortschritte, und das Team kann den Kurs auf der Grundlage der tatsächlichen Nutzung statt der prognostizierten Nutzung anpassen. Die horizontale Aufteilung steigert die Velocity-Werte, während das für die Nutzer sichtbare Produkt über mehrere Sprints hinweg unverändert bleibt.

Wann ist eine horizontale Aufteilung zulässig?

Wenn es sich um grundlegende Plattformarbeiten handelt, bei denen bis zur Fertigstellung kein für den Nutzer sichtbarer Teil vorliegt – beispielsweise die Migration von Authentifizierungsanbietern, der Austausch eines Queue-Backends oder die Erneuerung der Deployment-Pipeline –, dann handelt es sich um Projekte und nicht um Stories: Bewerten Sie diese entsprechend und kommunizieren Sie den Zeitplan, anstatt so zu tun, als ließen sie sich aufteilen.

Weiterführende Literatur

• Aufteilung von User Stories – das komplette Toolkit und wie man eine echte Aufteilung von einer vorgetäuschten unterscheidet.
• SPIDR-Story-Aufteilung – fünf zuverlässige vertikale Schnitte.
• Agile Schätzung: Der umfassende Leitfaden – hier finden Sie alles zum Thema.