Der richtige Zeitpunkt der Aufwandsschätzung ist ein wichtiger Aspekt für jedes Software-Entwicklungsprojekt. Voraussichtliche Aufwände sollen möglichst früh und möglichst genau geschätzt werden. Die erste Aufwandsschätzung wird von den Projektmanagern meistens sehr früh eingefordert. Meistens sind das aber Schätzwerte die zu ungenau sind. Die Cone of Uncertainty, eine Verlaufsbeschreibung von Unsicherheiten in einem Projekt, besagt, dass eine Schätzung vor der Anforderungsphase im Durchschnitt noch mit einer Unsicherheit von Faktor 4 belastet ist. Die Varianz von 4x bis 0,25 bedeutet, dass ein auf 12 Monate geschätztes Projekt am Ende tatsächlich zwischen 3 und 48 Monate dauern kann.[1]

Cone of Uncertainty[2]

Infolgedessen verweigern die Entwickler Aussagen zu jeglichen Aufwänden um bei einem Scheitern die Konsequenzen einer verbindlichen Schätzung zu umgehen. Eine verbindliche Schätzung wird in der mir bekannten Praxis generell nicht gegeben, trotzdem werden die Entwickler wegen Aussagen wie „Wir werden ungefähr zu diesem Zeitpunkt fertig“ an die Wand genagelt, wenn dieser Zeitpunkt überschritten wird.

Trotzdem ist es wichtig, dass die Entwickler beziehungsweise der Projektleiter eine Schätzung am Anfang eines Projektes abgeben. Diese Angaben sind wichtig für die Projek- und Ressourcenplanung. Agile Teams schätzen Aufwände nur für kurze Sprints, diese reichen aber für eine langfristige Projektplanung nicht aus. Beiden Parteien, dem Programm- oder Multiprojektmanagement und den Entwicklern muss die Unsicherheit einer Schätzung bewusst sein. Mit einer strukturierten Vorprojektphase die konform mit den agilen Prinzipien ist, können zudem die Unsicherheitsfaktoren (auch wenn es nur zu einem geringen Teil ist) gemindert werden. Diese Schätzungen sollten mit jedem Sprint oder Meilenstein nachjustiert werden.