Scrum und XP im harten Projektalltag

26 | SCRUM UND XP IM HARTEN PROJEKTALLTAG
Interessant ist dabei, dass sich die tatsächliche
Entwicklungsgeschwindigkeit nur aus den anfangs geschätzten Story-
Aufwänden errechnet. Spätere Korrekturen an der Schätzung werden
nicht miteinbezogen.
Ich höre Sie schon sagen: "Was soll das denn? Ob man eine hohe oder
niedrige Entwicklungsgeschwindigkeit hat, hängt dann ja von hunderten
Faktoren ab: von dusseligen Entwicklern, falschen Schätzungen,
nachträglichen Anforderungen, Störungen während des Sprints."
Sie haben Recht. Es ist nur eine vage Zahl, aber die ist besser als gar
keine Zahl. Außerdem liefert sie harte Fakten und zeigt, wie viel Sie, im
Gegensatz zu dem was Sie sich vorgenommen haben, wirklich geschafft
haben. Gründe für die Abweichung werden nicht betrachtet.
Und was ist mit Stories, die nur fast abgeschlossen sind? Kann man nicht
einen Teil Ihrer Punkte in die Berechnung der
Entwicklungsgeschwindigkeit mit einfließen lassen? Nein, kann man
nicht! Scrum sowie andere Vorgehensweise aus dem Umfeld der Agilen
Softwareentwicklung und des so genannten Lean Manufacturing legen
großen Wert darauf, Dinge so zu beenden, so dass sie auslieferbar und
wirklich erledigt sind. Der Wert halbfertiger Arbeitspakete liegt bei Null;
wenn nicht gar im negativen Bereich. Wenn Sie mehr zum Thema wissen
wollen, empfehle ich Managing the Design Factory von Donald
Reinertsen oder eines der Bücher der Poppendiecks zu lesen.
Mit welchen magischen Formeln schätzen wir aber unsere
Entwicklungsgeschwindigkeit?
Zu ihrer Abschätzung hilft ein Blick in die nähere Projektvergangenheit.
Lag sie dort immer ungefähr bei X, gilt das vermutlich auch für den
nächsten Sprint.
Dieses Prinzip nennt man "das Wetter von gestern". Es funktioniert nur
dann, wenn das Team schon einige Sprints zusammen gearbeitet hat und
sich Arbeitsbedingungen wie die Teamgröße nicht ständig ändern. Das ist
natürlich nicht immer der Fall.
Im Detail läuft die Berechnung über die Ressourcenverfügbarkeit.
Angenommen wir planen einen dreiwöchigen Sprint (entspricht 15
Arbeitstagen) für ein vierköpfiges Team. Wenn Lisa davon zwei Tage und
Dave (generell nur zu 50% verfügbar) einen Tag Urlaub hat, ergibt das...