Scrum und XP im harten Projektalltag

36 | SCRUM UND XP IM HARTEN PROJEKTALLTAG
Beschreiben Sie mit einfachen Worten, wie ein typisches Testszenario
aussieht (so in der Art: "Tue dies, dann das und prüfe ob das passiert.")
Meiner Erfahrung nach sind es oft gerade die einfachen Beschreibungen,
die all jene Missverständnisse offen legen, die man lieber früh als spät
entdeckt.
Stories in mehrere Stories zerlegen
Eine Story, oder besser gesagt ihr Aufwand, sollte weder zu klein, noch
zu groß sein. Ein Stapel von 0,5-Punkte Stories führt nicht selten zu
Mikromanagement. 40-Punkte Stories laufen Gefahr, bis zum Sprint-Ende
nicht abgeschlossen zu werden und für das Unternehmen nur Kosten statt
Wert zugenerieren. Auch die Planung wird schwierig, wenn man bei einer
Entwicklungsgeschwindigkeit von z.B. 70 zwei 40-Punkte Stories im
Sprint unterbringen will. Mit einer Story unterfordern Sie das Team,
nehmen Sie beide, überfordern Sie es.
Ich habe die Erfahrung gemacht, dass sich eigentlich jede Story weiter
zerlegen lässt. Wichtig ist nur, dass auch diese kleineren Stories von Wert
für das Unternehmen sind.
Normalerweise bemühen wir uns, Stories zwischen zwei und acht Tagen
zu halten. Bei einer durchschnittlichen Entwicklungsgeschwindigkeit pro
Team von 40 bis 60, können wir je Sprint ungefähr zehn Stories
abarbeiten. Manchmal sind es nur fünf, ein anderes Mal 15. Mit so vielen
Karteikarten kann man immer noch problemlos hantieren.
Stories in Aufgaben zerlegen
Was, bitte, ist denn der Unterschied zwischen Aufgaben und Stories?
Gute Frage; der Unterschied ist aber leicht erklärt. Während die
Fertigstellung einer Story für den Product Owner von großem Belang ist,
gilt das für die Fertigstellung einzelner Aufgaben nur selten.
Beispielhafte Zerlegung einer großen Story in zwei kleinere Stories: