Story Splitting (2/4): Zerlegung in Komponenten?

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Was kommt beim Splitting einer User Story heraus? Wenn man diese Frage falsch beantwortet, folgt daraus ein gefährliches Vorgehen, dessen toxische Wirkung bei oberflächlicher Betrachtung leicht übersehen wird. Für mich gibt es nur eine richtige Antwort: Splitting einer User Story erzeugt zwei oder mehr neue User Stories, die die alte ersetzen. Wesentlich ist dabei nicht, wie man den Tickettyp nennt. Wichtig ist, dass die abgeleiteten, kleineren Tickets einen eigenständigen Wert für jemanden (außerhalb des Entwicklerteams) besitzen (vgl. dazu auch die INVEST-Kriterien).

Das ist nach meiner Beobachtung nicht selbstverständlich. Stattdessen sehe ich Teams, die die Story in sogenannte Work Items zerlegen, also in Teile, deren Summe das in der ursprünglichen Story gewünschte Feature implementieren. Die Teile besitzen jedoch keinen eigenständigen Wert. Bei dieser Vorgehensweise handelt es sich gar nicht um Story Splitting. Für diese Art von Zerlegung gibt es ein Wort: Es lautet Planung. Nur dass dieser Planungsschritt (fälschlicherweise) im Refinement und nicht im Planning passiert. Diese Sichtweise findet sich sogar in der Beschreibung des Plannings im Scrum Guide wieder:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.

Wer die Decomposition in technische Stücke im Refinement durchführt, sollte (hoffentlich) den Product Owner langweilen, auf jeden Fall aber jeden (Business) Stakeholder abschrecken. Damit wird es schwierig, im Refinement eine bereichsübergreifende Kollaboration (Business/Entwicklung) zu erreichen, wie sie beispielsweise das Manifest für agile Softwareentwicklung schon vor Jahrzehnten in seinen Prinzipien forderte.

Business people and developers must work together daily throughout the project.

Wenn die Zusammenarbeit nicht einmal in einem wichtigen Meeting wie dem Refinement stattfindet, wann denn sonst?

Die Kurzserie zu Story Splitting besteht aus vier Teilen:

1. Es ist eine Kunst, und wir brauchen Entwickler dafür
2. Zerlegung in Komponenten?
3. Nicht ohne meine Developer
4. Wasserfall ohne Plan

(rme)