Horizontales vs. vertikales Schneiden

Vertikale Schnitte liefern Wert; horizontale Schnitte liefern Versprechen. Warum eine Aufteilung nach Technologieebenen den Wert verzögert und wie man nach Nutzerergebnissen unterteilt, damit in jedem Sprint etwas ausgeliefert wird.

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, die nichts enthalten.

Der Unterschied

Bei der horizontalen Aufteilung erfolgt die Arbeitsteilung entlang der Architekturebenen: Frontend in diesem Sprint, Backend im nächsten, Datenbank im darauffolgenden Sprint. Die Arbeit lässt sich zwar in Sprints einteilen, doch kein einzelner Sprint bringt etwas hervor, 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 Eingabefall abdeckt. Das Team liefert pro Ausschnitt weniger, 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.

A layered cake split horizontally versus the same cake split vertically Horizontal Vertical UI Logic Data → shipped nothing for users until all three land UI Logic Data slice 1 ships end-to-end, on its own sprint 1: nothing usable sprint 1: working slice
Horizontale Schnitte werden schichtweise ausgeliefert. Vertikale Schnitte werden als Arbeitsspalte ausgeliefert: jeweils ein kleiner Ausschnitt aus jeder Schicht, der sofort nutzbar ist.

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, die jedoch fast immer der Überlegung weicht: „Wir können die Antwort fest programmieren, 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 Infrastrukturkomponenten verfügen vor ihrer Fertigstellung über keinen für Benutzer sichtbaren Teil: die Migration zu einem neuen Authentifizierungsanbieter, der Austausch eines Warteschlangen-Backends oder die Erneuerung der Bereitstellungs-Pipeline. Dies sind Projekte, keine 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, handelt es sich nicht um ein 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 unterteilt, sodass jeder „Slice“ einen schmalen Schnitt durch alle Schichten (Benutzeroberfläche, Logik und Daten) darstellt, der dem Benutzer tatsächlich einen Nutzen bietet, 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 kein einzelner Sprint etwas hervorbringt, das ein Benutzer nutzen kann. Bei der vertikalen Aufteilung erfolgt die Unterteilung nach Benutzerergebnissen, 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 Teilziel 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 und nicht anhand von Prognosen anpassen. Durch horizontale Aufteilung lassen sich die Velocity-Werte steigern, 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