Agile Methoden haben die Art und Weise revolutioniert, wie Software und Produkte entwickelt werden. In kurzen Zyklen wird neue Funktionalität gebaut, die potenziell geliefert werden kann. Dadurch bekommen wir schnell Feedback vom Benutzer und können ggf. Anpassungen machen.
Eine der zentralen Praktiken in der Agilität ist das Aufteilen von User Stories, auch User Story Splitting genannt.
In diesem Artikel gehe ich darauf ein, welche Probleme wir mit User Story Splitting lösen können. Daraus wirst du erkennen, warum User Story Splitting sinnvoll ist. Und im Anschluss schauen wir uns an, wie User Story Splitting genau funktioniert und wo man es anwenden kann.
Übersicht
- Definition of Done nicht erfüllt – was nun?
- Warum unfertige User Stories ein Problem sind
- Was ist das 90% Syndrom
- Warum eigentlich User Story Splitting?
- Wie funktioniert User Story Splitting?
- Geht Splitting nur bei User Stories?
Definition of Done nicht erfüllt – was nun?
Folgendes Szenario kann selbst den besten Scrum-Teams passieren. Am Ende eines Sprints kann eine Story nicht vollständig im Sinne der Definition of Done abgeschlossen werden. Dann stellt sich die Frage, wie mit der halbfertigen Lösung umgegangen werden soll.
Die kurze Antwort darauf ist einfach. Die Story gilt als nicht umgesetzt (in Scrum gibt es kein “halbfertig”). Sie wird also auch kein Bestandteil eines Release-Pakets und wandert zurück ins Backlog. Dort wird sie wie jede andere Story behandelt.
Product Owner beschweren sich häufig, dass dies meist ausgerechnet bei den – aus ihrer Sicht – wertvollsten User Stories passiert. Die wertvollsten sind meist auch eher komplexere User Stories.
Gemäss Scrum werden die geschätzten Story Points einer unfertigen User Story nicht in der Velocity berücksichtigt.
Im Sprint Review werden nur fertige Stories präsentiert. Diese Scrum Regel macht durchaus Sinn. Dadurch werden Teams davon abgehalten, sich selbst und den Stakeholdern ein falsches Bild ihres Fortschritts zu vermitteln.
Warum unfertige User Stories ein Problem sind
Natürlich kann es einmal passieren, dass eine User Story nicht im Sprint fertig wird. Wenn dies aber regelmässig passiert, führt das zu folgenden Problemen
- die Velocity ist inkonsistent und wird unberechenbar
- das Sprint Planning wird dadurch zur Herausforderung
- wir können weniger Fortschritt vorzeigen und erleben, da Arbeit nicht abgeschlossen ist
- Sprint Reviews werden zur Enttäuschung, weil die Arbeit nicht erledigt ist
Was ist das 90% Syndrom?
Vielleicht hast du das 90% Syndrom bereits erlebt. Die Entwickler fangen die Arbeit an einer Story an. Nach einer Woche erhältst du die Info, dass die Story zu 90% fertiggestellt ist.
Im Laufe der zweiten Woche ergeben sich neue Erkenntnisse und unvorhergesehene Mehraufwände. Die Entwickler arbeiten fleissig weiter. Am Ende der Woche sind sie zu 90% mit der Story fertig.
Dasselbe wiederholt sich in der dritten Woche…
Eigentlich wollen wir im agilen Umfeld nicht einen genauen prozentualen Stand wissen, da man sich dabei meist verschätzt. Wir stellen nur eine ganz einfache Frage: ist die Story fertig, oder nicht?
Warum eigentlich User Story Splitting?
In Scrum wollen wir kontinuierlich Mehrwert für den Nutzer schaffen. Wir teilen unsere Arbeit in kleine Schritte auf. So erhalten wir bei jedem erledigten Schritt vom Nutzer Feedback, können daraus lernen und ggf. Anpassungen vorzunehmen.
Bevor wir also eine potenziell zu grosse User Story in den Sprint ziehen, splitten wir sie lieber in kleinere Stücke auf. Dadurch machen wir sie besser handhabbar. Und wir benötigen weniger “Glück”, zum sie in einem Sprint fertig zu stellen.
User Story Splitting ist besonders bei komplexen User Stories nützlich. Wir reduzieren damit das Risiko, dass User Stories nicht in einem Sprint fertig werden. Durch die Aufteilung in kleinere, überschaubarere Häppchen können Teams sich auf spezifische Aufgaben konzentrieren und effizienter Fortschritte erzielen.
Wie funktioniert User Story Splitting?
Grob gesagt gibt es verschiedene Methoden für das Aufteilen von User Stories, darunter:
- Funktionale Aufteilung
Wir teilen die User Stories basierend auf der von ihnen bereitgestellten Funktionalität auf.
Beispielsweise können wir eine User Story zur Erstellung eines neuen Benutzerkontos wie folgt aufteilen:- Benutzerregistrierung
- Anmeldung
- Passwortwiederherstellung
- Vertikale Aufteilung
Wir teilen die User Stories nach Merkmal oder Komponente auf.
Beispiel einer User Story zur Implementierung einer Suchfunktion:- Design der Suchleiste
- Anzeige der Suchergebnisse
- Implementierung des Suchalgorithmus
- Horizontale Aufteilung
Diese Technik beinhaltet das Aufteilen von User Stories nach Benutzerrolle oder Persona.
Somit erhält jede Rolle eine eigene User Story.- User Story für Normalbenutzer
- User Story für Admin-Benutzer
- User Story für Kunde
User Story Splitting hilft Teams dabei, besser zusammenzuarbeiten. Komplexe User Stories werden in kleinere Stories aufgeteilt. Diese können unabhängig voneinander bearbeitet werden.
Dadurch können Teammitglieder an spezifischen Aufgaben arbeiten und effizienter Fortschritte erzielen. User Story Splitting hilft Teams
- ihren Entwicklungsprozess zu verbessern und
- bessere Software in kürzerer Zeit liefern
Geht Splitting nur bei User Stories?
Die User Story Splitting Strategien funktionieren übrigens auch bei grösseren Arbeitspaketen. Ob Epics, Features oder im klassischen Umfeld spielt dabei nur eine untergeordnete Rolle.
In unserem Booklet “User Story Hacks” gehen wir auf die einzelnen Splitting Strategien näher ein: Spikes, Paths, Interfaces, Data, Business Rules, Roles, Defer Quality, CRUD Operations. Darüber hinaus bekommst du noch viele weitere, wertvolle Tipps & Tricks für einfach bessere User Stories.
Klicke hier um dein kostenloses Exemplar noch heute zu erhalten.
Aufgrund von vielen interessierten Rückfragen habe ich mich dazu entschlossen, für jede Splitting Strategie einen eigenen Artikel zu schreiben. Dort wird die jeweilige Strategie im Detail erklärt und wir gehen sie anhand eines Beispiels zusammen durch.
Deutsch (Schweiz) 
English