Programmierer sind die schlechtesten Schätzer der Welt. Behauptet zumindest Anders Abel in seinem Blog „Passion for Coding“. Der schwedische Software-Consultant geht noch weiter und präsentiert eine mathematische Formel, um die tatsächlich benötigte Zeit zu ermitteln: Man nehme die geschätzte Zeit des Entwicklers, multipliziere sie mit Pi und rechne sie in die nächsthöhere Zeiteinheit um. Schätzt der Entwickler also einen Manntag, wird er – nach Abel – 3,14 Wochen benötigen.

Sicherlich eine provokant formulierte These, nichtsdestotrotz ist das Thema Aufwandsschätzung ein Dauerbrenner in der Softwareentwicklung – und nicht nur hier, denn seit agile Methoden abteilungs- und branchenübergreifend im Einsatz sind, beschäftigt die Frage nach der Kalkulation des Aufwands auch Non-Software-Teams.

Projektmanager beklagen sich, dass die Schätzungen in etwa so verlässlich seien wie die Bahn oder die Wettervorhersage. Aber warum ist das so? Was macht es so schwierig, den Aufwand eines Projekts zu kalkulieren? Und noch wichtiger: Wie lässt sich die Fehlerquote minimieren?

„Ach, das haben wir gleich fertig!“ Oder?

Auch Sie kennen die Frage aller Fragen: “Wie lange wird es dauern?“ Der Projektmanager oder Kunde will möglichst schon zu Beginn des Projekts wissen, welche Ressourcen bereitgestellt werden müssen. Das ist verständlich.

Doch sehen wir uns das Problem aus der Sicht des Teams an. Sofern es sich um ein richtiges Projekt handelt (und nicht um eine Routineaufgabe), betritt das Team Neuland. Er soll etwas entwickeln, das es so noch nicht gibt. Das einzige, was er wirklich sicher weiß, ist, dass sich die Anforderungen des Projekts garantiert noch zigmal ändern werden. Vielleicht muss er auch mit neuen Tools oder in einem neu zusammengestellten Team arbeiten. Jede Menge unbekannte Faktoren also, die eine korrekte Aufwandsschätzung ungemein schwierig machen.

Hinzu kommt eine psychologische Komponente, die „Theorie der Selbstüberschätzung“: Es ist wissenschaftlich erwiesen, dass Menschen insbesondere bei schwierigen oder umfangreichen Aufgaben dazu neigen, die benötigte Zeit zu unterschätzen. Je kleiner hingegen die Aufgabe ist, desto niedriger wird die Fehlerquote – einer der Gründe für den Erfolg von agilen Methoden wie Scrum, die Projekte in möglichst kleine, überschaubare Teilaufgaben zerlegen.

„Programmers are the most optimistic bunch of people I have ever come across. Ask us how long something will take and chances are our estimates will be way off.“
Swizek Teller, Blog-Autor

Schätzen kann man lernen

Die gute Nachricht: Es gibt inzwischen zahlreiche Methoden und Tricks, mit deren Hilfe man zu ordentlichen Schätz-Ergebnissen kommt.

Aber nochmal zurück zum Ausgangspunkt: Agil arbeitende Teams sollen also zu einem möglichst frühen Zeitpunkt möglichst schnell eine möglichst genaue Schätzung für ein Projekt abgeben, über das sie noch kaum etwas wissen. Nach gesundem Menschenverstand müssten die Teammitglieder sagen: „Auf dem derzeitigen Stand können wir leider keine zuverlässige Schätzung abgeben. Aber fangen wir doch einfach mal an, unsere Aufwandsprognose wird im Verlauf des Projekts immer konkreter werden, versprochen!“

Aber das setzt viel Vertrauen voraus und die Bereitschaft, sich mit den erwähnten Unwägbarkeiten zu arrangieren. Nicht in jedem Unternehmen sind diese Voraussetzungen gegeben. Und damit sind wir wieder bei der Notwendigkeit von Schätzungen (die übrigens auch in vielen agil arbeitenden Unternehmen an der Tagesordnung sind, denn so ganz ohne läuft es unserer Erfahrung dann doch eher selten…)

Fazit: Ohne Schätzen geht es nicht

Verlässliche Aufwandschätzungen sind wichtig, denn sie nehmen für den Auftraggeber zumindest einen Teil der Unsicherheit aus dem Projekt. Doch bleibt es insbesondere bei Großprojekten oder schwierigen Projekten nicht aus, dass die erste Schätzung daneben liegen kann – und beileibe ist dann nicht immer das Team schuld, sondern schlicht und ergreifend die Komplexität des Projekts und die Unvorhersehbarkeit vieler Faktoren. Das ist nicht ideal, aber normal.

Sie können lediglich die die Fehlerquote beeinflussen, indem Sie das Schätzen üben und mit Schätzmethoden arbeiten, die zu Ihrem Projekt und Ihrem Team passen. Wichtig ist auch, dass sich das Team regelmäßig hinterfragt, warum die zurückliegenden Schätzungen daneben gelegen haben – um diesen Fehler das nächste Mal nicht mehr zu machen.

Und wie läuft das mit dem Schätzen nun genau?

In Teil 2 dieses Artikels werden wir auf Unterschiede zwischen traditioneller und agiler Aufwandsschätzung eingehen und Begriffe wie „Velocity“ und „Story Points“ erläutern.

In Teil 3 stellen wir dann einige gängige Schätzmethoden wie das populäre „Planning Poker“ nach Mike Cohn, „Magic Estimation“ nach Lowel Lindstorms oder das „Team Estimation Game“ nach Steve Bockman vor.

Haben Sie Fragen zur Aufwandsschätzung oder zu einer speziellen Schätzmethode? Melden Sie sich gerne bei uns!

Beitrag teilen

Alle Blogartikel
Fasziniert von agilen Methoden begleitet Matthias Pauers Führungs­kräfte auf dem Weg zum „Agile Leader“ und unterstützt Organisationen beim Change Management. Seine Schwer­punkte sind Unternehmens­kultur und Führung, Coaching, Anforderungs­management und Design Thinking.

Beitrag teilen