In Projekten gehören Probleme und deren Lösung zur Tagesordnung; IT-Projekte bilden dabei keine Ausnahme. Neu ist hingegen der Ansatz, typische Probleme in IT-Projekten durch den punktuellen Einsatz von Scrum-Techniken in den Griff zu bekommen. Das mag auf den ersten Blick absurd erscheinen, da vielerorts die Meinung vorherrscht, Scrum können nur dann funktionieren, wenn es zu 100% in einer Organisation eingeführt ist. Setzt man sich jedoch über dieses puristische Denken einmal hinweg, bietet der Einsatz von Scrum-Techniken völlig neue Möglichkeiten, um Krisensituationen in IT-Projekten effizient zu bewältigen.

In diesem zweiten und abschließenden Teil erfahren Sie u.a., wie Sie in IT-Projekten mit einem ausgeklügelten Vorgehen eine belastbare Aufwandsschätzung erhalten und Grundcharakteristika von Scrum, wie Sprints oder Reviews, einfach in einer Organisation einführen können.

Das "Der Glaube an die Aufwandschätzung"-Problem

Im Gespräch mit Frau Müller (Leiterin Fachkonzeption in unserem Beispielprojekt „HelloWorld“) hat Herr Wolf (Berater und Spezialist für Projektrettung) ein weiteres typisches Problem entdeckt. Das Entwicklungsteam ist immer überplant. Im schlimmsten Fall liefert das Team zum vereinbarten Liefertermin nur einen Bruchteil der Funktionalität. Ein weiteres Zeichen für eine Überplanung ist auch, wenn jedes Mal zum Ende des Releases sehr hart gekämpft werden muss, z.B. mit Wochenendarbeit und vielen Überstunden.

Wie wurde bisher bei "HelloWorld" geplant? Zum einen schätzte das Entwicklungsteam den Entwicklungsaufwand für jedes angeforderte Thema in Personentagen. Zum anderen ermittelte der Entwicklungsleiter, wie viele Personentage das Entwicklungsteam im Zeitraum bis zum Release erbringen kann. Dann sagte der Entwicklungsleiter so viele Themen zu, bis die Summe des Entwicklungsaufwands für die zugesagten Themen gleich der Personentage war, die das Team bis zum Release leisten konnte.

Tatsächlich hatten die Entwickler für das Release so viele Personentage gearbeitet wie geplant. Dennoch wurden einige Themen nicht geliefert. In der Konsequenz waren die Aufwandsschätzungen offensichtlich fehlerhaft. Dies bedeutet, dass die Entwickler wohl mehr Personentage für die gelieferten Themen benötigten, wodurch ihnen nicht mehr genügend Zeit für die restlichen Themen zur Verfügung stand. Zudem hatten sie ggf. an Themen gearbeitet, die nicht rechtzeitig fertig gestellt wurden und somit erst (evtl.) im nächsten Release ausgeliefert werden können.

Ohne Zeiterfassung keine belastbaren Daten

Der tatsächlich benötigte Aufwand pro Thema war dem Entwicklungsleiter nur ungefähr bekannt, da die Entwickler es mit der Zeiterfassung nicht so genau nahmen. Damit lässt sich auch aus dem Vergleich des Ist-Aufwands mit dem Plan-Aufwand kein zuverlässiger Faktor errechnen, um den die Entwickler sich typischerweise verschätzten. Es blieb ihm nur, einen Faktor zu raten oder nach Bauchgefühl festzulegen.

Für das nächste Release von "HelloWorld" liegen bereits alle Aufwandsschätzungen vor. Da sie mit derselben Schätzmethode von denselben Entwicklern durchgeführt wurden, liegt es nahe, dass sie ebenfalls fehlerhaft sind. Behält der Entwicklungsleiter das bisherige Vorgehen bei der Releaseplanung und Aufwandsschätzung bei, wird das Entwicklungsteam wieder überplant sein.

Die Frage für den Entwicklungsleiter lautet nun, wie er künftig eine realistische Planung erstellen kann. Wie lässt sich die Erfahrung aus den vorherigen Releases in der Planung sinnvoll berücksichtigen? Wie kann er den Faktor ermitteln, um den sich typischerweise verschätzt wird? Er bittet Herrn Wolf um Rat. Herr Wolf setzt die Planung neu auf.

Einsatz von Velocity und Story Points

Für die Neuplanung nutzt Herr Wolf die in der agilen Planung eingesetzten Konzepte von Story Points und Velocity.

Story Points…

Story Points sind relative Aufwandsschätzungen. Man definiert eine überschaubare Referenzaufgabe und weist ihr den Wert von z.B. zwei Story Points zu. Jetzt werden alle anderen Aufgaben relativ zu dieser Referenzaufgabe geschätzt. Ist etwas doppelt so komplex und aufwendig bekommt es vier Story Points. Man versucht sich bei der Aufwandschätzung davon zu lösen, wie viele Entwicklungstage man konkret zur Umsetzung benötigt und eher die Komplexität der Aufgabe einzuschätzen. Story Points haben also nur einen indirekten Bezug zum Realisierungsaufwand. Komplexe Themen dauern länger, weniger komplexe eben kürzer. Wie dieser Bezug genau ist, ermittelt man mit Hilfe der Velocity.

…und Velocity