Die Aufwandsschätzung bildet einen zentralen Faktor in jeder Form von Projektmanagement. Gerade komplexe Projekte wie in der Softwareentwicklung stellen in dieser Hinsicht eine echte Herausforderung dar. Wie in vielen anderen Bereichen des Projektmanagements zeigen sich agile Methoden hier im Vorteil. Ein entscheidendes Stichwort ist hierbei die vergleichende Schätzung.
Die Aufwandsschätzung - worum geht es dabei?
Aufwandsschätzungen sind deshalb so wichtig für jedes Projekt, weil es hier um die Kosten geht. Projekte müssen am Ende rentabel sein. Mit einer Schätzung des entstehenden Aufwandes versucht man, die Rentabilität bereits vor und während der Durchführung eines Projektes zu sichern. Unrentable Projekte verbrauchen unnötige Ressourcen und Zeit. Davor will sich jeder Projektmanager schützen. Im Notfall muss während des Projektes die Reißleine gezogen werden, wenn sich herausstellt, dass der Aufwand als zu niedrig eingeschätzt wurde. Der Aufwand kann in einer Projektplanung nur eine Schätzung sein. Die genauen Kosten ergeben sich erst aus der Durchführung des Projektes. In der Regel muss die Schätzung somit auf Erfahrungswerten mit Blick auf frühere Projekte entstehen. Verschiedene Projektmanagementsysteme bedienen sich der einen oder anderen Methode (Metode) der Aufwandsschätzung. Wir wollen im Folgenden sehen, was agile Systeme dabei grundsätzlich anders machen.
Die Schätzung ist eine Verpflichtung oder nicht?
Realistische Aufwandsschätzungen sind immer eine unsicherer Faktor. Man kann sich dieser Herausforderung auf unterschiedliche Art und Weise nähern. Im klassischen Projektmanagement bedient man sich dabei einer Verpflichtung. Man nimmt aus Erfahrungswerten früherer Projekte heraus an, dass sich der Aufwand in dieser und jener Art und Weise entwickeln wird. Eine Methode im klassischen Projektmanagement ist dabei der Top-Down Ansatz. Der Auftraggeber gibt dabei einen bestimmten Aufwandsrahmen vor, an den sich der später das bearbeitende Projektteam zu halten hat. Greift der Auftraggeber bei der Schätzung daneben, steckt das Projektteam in der Folge häufig viel Arbeit und Zeit in das Projekt, um dann doch mit einem Projektabbruch konfrontiert zu sein. Die möglichen Erfahrungen und Kenntnisse des Projektteams bleiben unberücksichtigt. Dabei sind es gerade sie, die täglich mit Projekten beispielsweise in der Softwareentwicklung zu tun haben. Bei dieser Methode hat die Schätzung einen verpflichtenden Charakter. Auch bei der Bottom-Up Methode ergibt sich eine Verpflichtung. Allerdings findet hier eine Detailplanung für jedes bereits festgelegte Arbeitspaket statt. Das Projektteam bestimmt also entscheidend über den geschätzten Aufwand mit. Beide Methoden zur Schätzung aus dem klassischen Projektplanungsbereich führen häufig zu Fehleinschätzungen. Das liegt unter anderem daran, dass die klassische Projektplanung eine fixe Angelegenheit ist, bei der das Projekt im Vorhinein geplant und festgelegt wird. Es fehlt bei der Projektdurchführung häufig die Flexibilität, um auf veränderte Anforderungen, die sich erst mit den ersten Schritten im Projekt ergeben haben, reagieren zu können. Das betrifft dann auch die Kostenseite. Besonders komplexe Projekte werden häufig nicht richtig eingeschätzt.
Wie verhält es sich bei agilen Projektmanagementmethoden?
Die Schätzung ist keine Verpflichtung für das Projektteam
Im agilen Bereich werden Aufwandsschätzungen nicht als Verpflichtung betrachtet. Das wäre auch gar nicht denkbar, weil die agile Planung nicht von fixen, bereits feststehenden Projektschritten ausgeht. Agile Planer sind sich der Tatsache bewusst, dass Aufwandsschätzungen auf Ereignissen und Projekten in der Vergangenheit beruhen. Sie sind deshalb per se mit einem großen Unsicherheitsfaktor behaftet. Es wirken komplexe Größen und Faktoren auf die Schätzung ein, die eine ständige Veränderung bewirken können. Das heißt aber nicht, dass agile Projektteams völlig losgelöst von Aufwand und Zielen arbeiten würden. Auch sie verpflichten sich. Allerdings tun sie es in anderer Weise. So verpflichtet man sich bei der Scrum Methode auf das jeweilige Sprintziel. Dabei geht es um ein inhaltliches Ziel, welches das Projekt in der einen oder anderen Weise voranbringen wird. Die Schätzung beim Aufwand dagegen ist keine Verpflichtung. So sind agile Planer in Projekten auch nicht gefährdet, etwa Qualitätsanforderungen oder inhaltliche Aspekte zu unterlaufen, um im Rahmen der Schätzung zu bleiben. Das passiert im klassischen Projektmanagement öfter als man denkt.
Der vergleichende Ansatz
Agile Projektplanungen arbeiten mit einem vergleichenden Ansatz bei der Schätzung. Wie kann man sich das vorstellen? Vielleicht kennen Sie ein bestimmtes Phänomen, mit denen Menschen allgemein bestimmte Fragen beantworten. Fragt man willkürlich unterschiedliche Menschen nach den Einwohnerzahlen von bestimmten Ländern oder Großstädten, können diese häufig keine konkreten Zahlen nennen. Bittet man die Menschen aber darum, Großstädte und Länder nach ihrer Einwohnerzahl aufsteigend- oder absteigend in eine Reihenfolge zu bringen, ergeben sich oft sehr realistische Ergebnisse. Ähnlich wird der Aufwand in agilen Projekten geschätzt. Man setzt dabei den Aufwand der unterschiedlichen User Storys in Beziehung zueinander. Mit anderen Worten: Man führt Vergleiche für einzelne Projektanforderungen durch. Ausgehend von einer User Story - das ist eine konkrete Anforderung in der Softwareentwicklung in dem jeweiligen Projekt - beschäftigt sich das ganze Team mit der Schätzung des Aufwandes für diesen konkreten Teilschritt. Viele agile Planer setzen dabei als Maßeinheit Story Points ein. Dieser etwas abstrakte Begriff kann schnell anschaulicher werden. Das gelingt beispielsweise mit der T-Shirt Methode. Bekanntlich werden die Größen bei T-Shirts mit den Buchstaben XS, S, M, L, XL, XXL bezeichnet. In agilen Projekten steht XS für einen Story Point, S für zwei Points. Das wird so fortgeführt, wobei man ab Größe L etwa schon bei 5 Story Points ist und bei XL bei 8. Wenn jetzt über den Aufwand für eine bestimmte Anforderung im Entwicklungsprojekt gesprochen wird, lautet die Aussage zum Beispiel: Für die User Story 1 wird der Aufwand auf S geschätzt, für die User Story 2 auf L. Damit bekommen alle Beteiligten ein Gefühl dafür, wie sich die Kosten für eine jeweilige Anforderung zueinander verhalten.
Planning Poker
Eine weitere Methode der Aufwandsschätzung in agilen Projekten ist Planning Poker. Dabei wird mit speziellen Karten gearbeitet. Mit diesen Karten kann jedes Teammitglied bei der Schätzung des Aufwands für eine bestimmte Anforderung im Projekt eine Schätzung abgeben. Die jeweilige Karte mit einem Wert wird dabei vom Teammitglied zunächst verdeckt auf den Tisch gelegt, bis alle Teammitglieder eine Karte für die Schätzung ausgewählt haben. Danach werden die Karten offengelegt. Entsprechen sich alle Karten, gilt diese Schätzung. Gibt es Abweichungen, vertieft das Team seine Diskussion, bis eine Einigung erreicht wird. Es sollte in diesem Beitrag auch der Hinweis nicht fehlen, dass manche agile Projektplaner insgesamt auf eine Schätzung für den Aufwand verzichten. Sie halten die Schätzung für eine Zeitverschwendung, weil sie immer mit Fehlern behaftet ist.
Am Ende stellen wir uns die entscheidende Frage: Schätzen agile Planer den Aufwand realistischer ein als klassische Planer? Tatsächlich kommen agile Teams mit den Aufwandsschätzungen häufiger besser zurecht als klassische Teams. Das liegt aber auch an der inneren Systematik von agilen Projektplanungssystemen. Diese arbeiten sich anforderungsbezogen von Projektschritt zu Projektschritt. Dabei ist die ganze Entwicklung dynamisch und wird immer wieder an sich ergebende neue Entwicklungen im Projekt angepasst. Folglich ist auch die Kostenseite inkrementell und wird kleinteilig präzise immer wieder auf veränderte Bedingungen zugeschnitten. Da außerdem in die Schätzung das gesamte Projektteam einbezogen wird, ist die Schätzung nicht nur demokratischer, sondern wird häufig auch von der Erfahrung aller Projektbeteiligten getragen. Agile Methoden bieten deshalb bei der Aufwandsschätzung große Vorteile. Davon kann man gerade bei komplexen Projekten wie in der Entwicklung von Software sehr profitieren. Ganz am Ende sollte ein weiterer entscheidender Punkt nicht fehlen: Agile Projekte werden in aller Regel viel kürzerer Zeit beendet als klassische Projekte. Das wirkt sich auf der Aufwandsseite aus.