Hilfe, unsere Product Backlog Items (PBIs) sind zu groß für einen Sprint! Mit dem Story Splitting Cheat Sheet geben wir Euch ein Hilfsmittel in die Hand, um große Product Backlog Items in sprint-gerechte und trotzdem wert-volle Häppchen zu zerlegen.
Weshalb sollte man Stories splitten?
Das Ziel der meisten Entwicklungsteams, egal ob agil oder nicht, ist es, aus Kundenwünschen ein gelungenes Produkt zu entwickeln. Bei der agilen Entwicklung wird dieses Produkt in möglichst kurzen Iterationen inkrementell entwickelt. Dadurch kann das Entwicklungsteam dem Kunden sehr schnell „etwas“ liefern. Dieses „etwas“ wird inkrementell weiterentwickelt, bis der Kunde mit dem Produkt zufrieden ist. Natürlich sollte das „etwas“ nicht einfach irgendwas sein, sondern ein wert-volles Zwischenprodukt. Der Wert kann aus zwei Teilen bestehen. Erstens lernt das Team nach jeder Lieferung etwas darüber, wie der Kunde das Produkt nutzt und wie sie es verbessern können: es erzeugt Wissen. Zweitens kann der Kunde das Zwischenprodukt bereits nutzen: es erzeugt Geld. Damit das funktioniert, muss das Zwischenprodukt natürlich entsprechend wert-voll „geschnitten“ sein.
Wieso ist wert-volles Splitten schwierig?
Produktentwicklern, die diese Art des „Schneidens mit Kundenwertfokus“ nicht gewohnt sind, fällt es naturgemäß schwer, aus eingefahrenen Denkmustern auszubrechen. Der erste Versuch, ein PBI in leicht verdauliche Häppchen zu zerlegen, wird daher oft entlang der Expertise der einzelnen Teammitglieder gemacht (siehe hierzu auch das Gesetz von Conway). Bei einem Softwareprodukt könnten dadurch zum Beispiel die folgenden Häppchen entstehen: Frontend, Middleware, Backend, nichtfunktionale Anforderungen. Das ist jedoch nichts anderes, als unter dem Deckmantel der Agilität wasserfallartig Aufgaben abzuarbeiten. Selbst wenn es einem Entwicklungsteam gelingt, in jeder Iteration eines dieser Häppchen fertigzustellen, ist frühestens nach vier Iterationen ein wert-volles Zwischenprodukt verfügbar. Wir nennen dies horizontales Splitting, weil die verwendeten Ebenen grafisch meist horizontal voneinander abgegrenzt sind.
Product Backlog Items schneiden für Produktentwickler
Besser ist es, PBIs vertikal zu schneiden. Dadurch entsteht in jeder Iteration ein vollständiger Durchstich. Das Team hat alle Technologien eingesetzt und gelernt, wie sie zusammenspielen (Wissen). Und der Kunde kann sich ein erstes Bild machen, wie sich das fertige Produkt anfühlt. Statt eines herausgeputzten Frontends ohne Funktionalität bekommt er eine installierbare Anwendung mit einem funktionsfähigen Usecase (Wert).
Ein Beispiel für vertikales Splitting bei einer Softwareanwendung ist, entlang der grundlegenden Persistenz-Funktionen zu splitten. Entwickler sprechen von CRUD = create, read, update, delete. Bei einem Warenkatalog-System ist das zum Beispiel: Artikel anlegen, Katalog anzeigen, Preis ändern, Artikel löschen. Eine andere Möglichkeit ist, alle nicht unbedingt notwendigen Produktbestandteile erst mal wegzulassen. Als Beispiel sei ein Kassensystem genannt, das in verschiedenen Ländern verschiedene Steuersätze und Rabattaktionen berücksichtigen soll. Die Kernfunktionalität ist das Aufaddieren der Preise. Steuern und Rabatte werden in nachfolgenden Iterationen geliefert. Dieses Beispiel stammt übrigens aus dem „Elephant Carpaccio“ Workshop von Alistair Cockburn. Dafür hat Henrik Kniberg eine ausführliche Anleitung geschrieben. Falls Euch das nicht reicht, kommen wir gerne vorbei und moderieren für Euch – schreibt einfach an info@emendare.de.
Es gibt natürlich noch viel mehr Arten, Stories zu splitten! Die haben wir für Euch in unserem übersichtlichen Story Splitting Cheat Sheet zusammengestellt:
Da findet Ihr jede Menge Anregungen und Beispiele, und es ist für jedes PBI ein passender Ansatz dabei. Oder habt Ihr ein PBI, von dem Ihr denkt, dass sich nicht kleiner schneiden lassen würde? Fragt uns gern! Wir beweisen Euch das Gegenteil.
