Viele Softwareprojekte beginnen mit einer scheinbar einfachen Frage:

„Wie lange dauert das?“

Kaum ein Thema sorgt in der Softwareentwicklung so regelmäßig für Diskussionen wie Aufwandsschätzungen. Manche Teams verbringen Stunden damit, Tickets zu bewerten, Story Points zu vergeben oder Release-Pläne zu erstellen. Andere Teams haben das Schätzen inzwischen komplett aufgegeben.

Beide Seiten haben gute Argumente.

Denn Schätzungen in der Softwareentwicklung bewegen sich immer in einem Spannungsfeld: Einerseits gibt es ein berechtigtes Interesse daran, Aufwand und Kosten einschätzen zu können. Andererseits arbeiten wir in einem komplexen Umfeld voller Unbekannter, Überraschungen und Abhängigkeiten. Genau das macht verlässliche Vorhersagen schwierig.

Die entscheidende Frage ist deshalb nicht, ob Schätzungen grundsätzlich gut oder schlecht sind. Die entscheidende Frage lautet:

Welches Ziel soll mit der Schätzung eigentlich erreicht werden?

Softwareentwicklung ist komplex – und Komplexität lässt sich nicht exakt planen

Viele Diskussionen rund um Aufwandsschätzungen beginnen mit einer stillschweigenden Annahme: Wenn ein Team nur genug Erfahrung hat und sorgfältig genug schätzt, dann müssten die Ergebnisse doch irgendwann zuverlässig werden. Genau darin liegt jedoch oft der Denkfehler.

Softwareentwicklung ist in vielen Fällen keine komplizierte, sondern eine komplexe Arbeit. Der Unterschied ist entscheidend. Ein kompliziertes Problem lässt sich analysieren, zerlegen und mit genügend Fachwissen relativ verlässlich planen. Ein komplexes Problem dagegen enthält viele Unbekannte. Während der Umsetzung entstehen neue Erkenntnisse, Anforderungen verändern sich, technische Randbedingungen tauchen plötzlich auf oder bisherige Annahmen stellen sich als falsch heraus.

Gerade bei innovativen oder fachlich anspruchsvollen Features zeigt sich das immer wieder:

• APIs verhalten sich anders als erwartet

• Fachliche Anforderungen sind unklar oder widersprüchlich

• Technische Altlasten bremsen die Umsetzung

• Neue Erkenntnisse verändern die ursprüngliche Lösungsidee

• Abhängigkeiten zu anderen Teams sorgen für Verzögerungen

All diese Dinge sind oft nicht einfach schlechte Planung. Sie sind ein natürlicher Bestandteil komplexer Arbeit. In der Projektmanagement-Theorie verdeutlicht das der Cone of Uncertainty (Trichter der Ungewissheit). Zu Beginn eines Features wissen wir am wenigsten über die tatsächlichen Hürden. Die Varianz einer Schätzung ist hier sehr hoch. Erst mit jedem Schritt der Umsetzung, mit jeder Zeile Code und jedem API-Call verengt sich der Trichter, weil Wissen die Annahmen ersetzt.

Und genau deshalb können Aufwandsschätzungen in der Softwareentwicklung niemals dieselbe Verlässlichkeit erreichen wie beispielsweise die Planung standardisierter industrieller Prozesse.

Warum manche Teams das Schätzen aufgegeben haben

Aus dieser Erfahrung heraus haben etliche Teams das Schätzen inzwischen bewusst reduziert oder ganz abgeschafft. Oft steckt dahinter die Erkenntnis, dass der Aufwand für die Schätzungen selbst enorm sein kann, während der tatsächliche Nutzen begrenzt bleibt.

Viele Teams kennen Situationen wie diese:

• Stundenlange Planning-Poker-Sessions

• Diskussionen über einzelne Story-Point-Unterschiede

• Detailplanungen Monate im Voraus

• Große Abweichungen zwischen Schätzung und Realität

• Rechtfertigungsdiskussionen bei Überschreitungen

Wenn Schätzungen anschließend hauptsächlich dazu genutzt werden, Teams an ursprünglichen Zahlen zu messen, entsteht schnell ein problematisches Verhalten. Der Effekt dahinter ist bekannt als Goodhart’s Law, welches sehr treffend beschreibt:

„When a measure becomes a target, it ceases to be a good measure.“

Sobald eine Schätzung zur Bewertung von Teams genutzt wird, verliert sie oft ihren ursprünglichen Nutzen. Dann wird nicht mehr offen über Risiken gesprochen. Dann werden Unsicherheiten versteckt. Dann versuchen Teams, möglichst defensiv zu schätzen. Die eigentliche Zusammenarbeit leidet darunter. Deshalb haben manche Teams entschieden, den Fokus stärker auf Durchsatz, kurze Feedbackzyklen und kontinuierliche Lieferung zu legen statt auf detaillierte Vorhersagen. Das ist nachvollziehbar. Aber daraus abzuleiten, dass Schätzungen grundsätzlich wertlos wären, greift ebenfalls zu kurz.

Schätzungen können auch einen wichtigen Nutzen haben

Schätzung als Katalysator für Diskussion

Der vielleicht wichtigste Nutzen von Schätzungen liegt oft gar nicht in der Zahl selbst. Der eigentliche Wert entsteht durch die Diskussion. Wenn in einem Team einzelne Entwickler:innen dieselbe Aufgabe völlig unterschiedlich einschätzen, dann ist das häufig ein Hinweis auf unterschiedliches Verständnis. Vielleicht hat jemand eine technische Abhängigkeit erkannt, die anderen noch nicht bewusst ist. Vielleicht interpretiert jemand die fachliche Anforderung anders. Vielleicht gibt es unterschiedliche Annahmen über Architektur, Qualität oder Umfang.

Genau diese Unterschiede sichtbar zu machen, ist enorm wertvoll. Denn solche Missverständnisse würden sonst oft erst während der Umsetzung auffallen – mit deutlich höheren Kosten. Die Schätzung wird dadurch zu einem Werkzeug für gemeinsames Verständnis. Und gemeinsames Verständnis ist einer der wichtigsten Faktoren für gute Zusammenarbeit im Team.

Aufwandsschätzung für ROI- und Priorisierungsentscheidungen

Es gibt außerdem ein völlig legitimes Bedürfnis, Aufwand grob einschätzen zu können.

Unternehmen investieren Geld in Softwareentwicklung und möchten verstehen:

• Welche Features liefern den größten Nutzen?

• Wo lohnt sich eine Investition?

• Welche Ideen sind wirtschaftlich sinnvoll?

• Welche Anforderungen sind möglicherweise zu teuer?

Ohne irgendeine Form von Aufwandseinschätzung wird es schwierig, solche Entscheidungen bewusst zu treffen. Gerade bei der Priorisierung eines Product Backlogs hilft die Kombination aus erwartetem Nutzen und geschätztem Aufwand enorm. Manche Features wirken auf den ersten Blick attraktiv, verlieren aber ihren Reiz, sobald klar wird, wie teuer oder riskant ihre Umsetzung wäre. Und genau das ist wertvoll. Denn manchmal ist die beste Entscheidung eben nicht, ein Feature umzusetzen.

Wo Aufwandsschätzungen gefährlich werden

Problematisch wird es meistens dann, wenn aus unscharfen Aufwandsschätzungen plötzlich vermeintlich belastbare Termin- oder Budgetpläne abgeleitet werden. Denn eine Schätzung enthält immer Unsicherheit. Und diese Unsicherheit verschwindet nicht einfach dadurch, dass man mehrere Schätzungen addiert.

Im Gegenteil.

Wenn ein Projekt aus vielen einzelnen Features besteht, dann addieren sich nicht nur die Aufwände, sondern auch die Ungenauigkeiten.

Trotzdem passiert in vielen Organisationen genau das:

1. Einzelne Features werden geschätzt

2. Die Zahlen werden addiert

3. Daraus entsteht ein Projektplan

4. Der Projektplan wird als verbindliche Erwartung kommuniziert

Dadurch entsteht schnell eine scheinbare Präzision, die in einem komplexen Umfeld gar nicht existieren kann. Aus einer groben Schätzung wird plötzlich ein fester Termin. Aus Unsicherheit wird vermeintliche Planungssicherheit. Und wenn die Realität später anders aussieht, wird oft dem Team vorgeworfen, falsch geschätzt zu haben. Dabei lag das eigentliche Problem meist gar nicht in der Schätzung selbst, sondern in der Art, wie mit ihr umgegangen wurde.

Ein besserer Ansatz: Rahmen statt Scheingenauigkeit

Statt aus unsicheren Aufwandsschätzungen präzise Termin- und Budgetpläne abzuleiten, ist es oft sinnvoller, bewusst mit Rahmenbedingungen zu arbeiten. Das funktioniert besonders gut im engen Dialog zwischen Entwicklung, Business und Kund:innen. Die zentrale Frage lautet dann nicht mehr:

"Wie lange dauert dieses komplette Feature exakt?"

Sondern eher:

"Wie viel Investition ist dieses Problem wert?"

Wenn klar ist, welchen Nutzen eine Funktionalität erzeugt, lässt sich auch einschätzen, welcher Aufwand wirtschaftlich sinnvoll wäre. Die Entwicklung bewertet anschließend, ob innerhalb dieses Rahmens eine sinnvolle Lösung realistisch erscheint. Dadurch verändert sich die Zusammenarbeit fundamental. Nicht mehr maximale Vollständigkeit steht im Mittelpunkt, sondern die Suche nach der kleinsten sinnvollen Lösung mit dem größten Nutzen.

Iteratives Vorgehen reduziert Risiko

Besonders wirksam wird dieser Ansatz in einer iterativ-inkrementellen Arbeitsweise. Anstatt monatelang auf eine große Komplettlösung hinzuarbeiten, wird Schritt für Schritt geliefert.

Das hat mehrere Vorteile:

• Fachliches Feedback kommt früher

• Risiken werden schneller sichtbar

• Fehlentwicklungen können früher korrigiert werden

• Investitionen lassen sich laufend neu bewerten

• Der tatsächliche Nutzen wird früher messbar

Dadurch entsteht die Möglichkeit, bewusst zu entscheiden, wann ein Feature „gut genug“ ist. Nicht jede zusätzliche Verbesserung rechtfertigt automatisch weitere Investitionen. Oft gibt es einen Punkt, an dem zusätzlicher Aufwand aktuell keinen ausreichenden Mehrwert mehr erzeugt. Dann kann es wirtschaftlich sinnvoller sein, die Weiterentwicklung zunächst zu stoppen und die Kapazität in andere Themen zu investieren. Genau diese Flexibilität geht häufig verloren, wenn bereits zu Beginn versucht wird, große Vorhaben vollständig durchzuplanen.

Nach meiner Erfahrung lassen sich Budget- und Terminrahmen auf diese Weise oft deutlich besser einhalten – und teilweise sogar unterbieten – als mit klassischen, detaillierten Schätzungen und Aufwandsplanungen. Nicht weil die Schätzungen genauer wären. Sondern weil kontinuierlich über Nutzen, Umfang und Prioritäten gesprochen wird.

Warum Vertrauen und psychologische Sicherheit dabei entscheidend sind

Dieser Ansatz funktioniert allerdings nur unter einer wichtigen Voraussetzung:
Vertrauen und psychologische Sicherheit.

In vielen Organisationen entsteht rund um Aufwandsschätzungen schnell eine Art Verhandlungssituation. Das Business versucht, Features möglichst „günstig“ umzusetzen. Entwicklungsteams planen möglichst viel Sicherheit ein. Dadurch ziehen plötzlich nicht mehr alle am selben Strang. Statt gemeinsam nach einer sinnvollen Balance zwischen Nutzen, Aufwand und Risiko zu suchen, beginnen beide Seiten häufig, ihre jeweilige Position zu verteidigen.

Die Folgen davon sieht man in vielen Organisationen:

• Risiken werden übertrieben oder kleingeredet

• Technische Komplexität wird überbetont oder heruntergespielt

• Schätzungen enthalten versteckte Puffer

• Fachliche Diskussionen werden politisch

• Entscheidungen entstehen aus Misstrauen statt aus Zusammenarbeit

Gute Entscheidungen brauchen aber das Gegenteil davon. Sie entstehen, wenn unterschiedliche Perspektiven offen eingebracht und gemeinsam verstanden werden. Das Business muss darauf vertrauen können, dass Entwicklungsteams sich nicht in technischen Spielereien verlieren oder unnötige Perfektion anstreben. Entwicklungsteams müssen gleichzeitig darauf vertrauen können, dass Themen wie Wartbarkeit, technische Risiken und nachhaltige Produktentwicklung ernst genommen werden — auch dann, wenn sie kurzfristig zusätzlichen Aufwand verursachen.

Fehlt dieses gegenseitige Vertrauen, wird Verhalten defensiv. Unsicherheiten werden spät angesprochen. Risiken werden abgesichert statt offen diskutiert. Schätzungen werden politisch.

Gerade iterative Produktentwicklung lebt aber davon, dass neue Erkenntnisse früh sichtbar werden — und bei komplexen Problemen entstehen diese Erkenntnisse oft erst bei der Umsetzung. Alle Beteiligten brauchen deshalb das Vertrauen, dass Risiken bewusst eingegangen werden dürfen und die Lösungsstrategie angepasst wird, sobald neue Erkenntnisse das erfordern. Das ist in den allermeisten Fällen viel produktiver, als der Versuch, schon bei der Schätzung alle Aspekte vorherzusehen und zu berücksichtigen. Aber das braucht genau das angesprochene Vertrauen und die Offenheit, Gegenargumente nicht als Störung zu sehen, sondern als Gelegenheit, gemeinsam bessere Lösungen zu entwickeln.

Ohne diese Offenheit scheitert der enge Dialog zwischen Business und Entwicklung häufig schon nach kurzer Zeit. Dann kehren Organisationen schnell wieder zu klassischen Kontrollmechanismen zurück — meist mit denselben Problemen wie zuvor.

Vom Programmierer:in zur Softwareentwickler:in

Und eine weitere wichtige Voraussetzung muss erfüllt sein: Softwareentwickler:innen müssen daran interessiert sein, das Problem zu verstehen, das mit ihrer Software gelöst werden soll. Sie müssen bereit sein, sich mit den fachlichen Anforderungen auseinanderzusetzen und sich aktiv an der Lösungsfindung zu beteiligen anstatt einfach nur Tickets abzuarbeiten. Nur so kann ein enger Dialog zwischen Business und Entwicklung entstehen, bei dem alle Perspektiven berücksichtigt werden.

Das bringt möglicherweise Herausforderungen mit sich und verlangt dem Team neue Fähigkeiten ab. Aber gerade im Zeitalter von KI ist es wichtiger denn je, dass Softwareentwickler:innen nicht nur technische Umsetzer:innen sind, sondern auch aktiv an der Gestaltung von Lösungen mitwirken. Denn KI kann zwar Code generieren, aber sie kann nicht die fachlichen Anforderungen verstehen oder die richtigen Prioritäten setzen. Das bleibt eine menschliche Aufgabe.

Fazit

Schätzungen in der Softwareentwicklung sind weder grundsätzlich gut noch grundsätzlich schlecht. Sie sind ein Werkzeug. Und wie bei jedem Werkzeug kommt es darauf an, wofür und wie es eingesetzt wird.

Schätzungen können helfen,

• gemeinsames Verständnis im Team aufzubauen

• Risiken sichtbar zu machen

• Diskussionen anzustoßen

• Aufwand und Nutzen gegeneinander abzuwägen

• Prioritäten bewusster zu setzen

Gefährlich wird es dann, wenn aus unsicheren Schätzungen vermeintlich präzise Termin- und Budgetzusagen entstehen. Die Lösung liegt deshalb nicht darin, Teams einfach „besser schätzen“ zu lassen. Der entscheidende Schritt ist vielmehr, sich bewusst zu machen, welches Ziel gerade verfolgt wird:

• Geht es um gemeinsames Verständnis?

• Geht es um Priorisierung?

• Geht es um ROI-Betrachtungen?

• Geht es um Budgetrahmen?

• Oder geht es um verlässliche Lieferzusagen?

Je nach Ziel braucht es unterschiedliche Vorgehensweisen.

Wer dagegen glaubt, dass Planungen automatisch zuverlässig werden, wenn Teams nur genug Zeit in immer präzisere Schätzungen investieren, läuft Gefahr, einer gefährlichen Illusion von Kontrolle zu erliegen. Und genau diese Illusion verursacht in vielen Organisationen mehr Probleme als die ursprüngliche Unsicherheit selbst.