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.
DE 
EN