Warum aus Schätzungen falsche Versprechen werden

Management braucht Planung.

Das ist legitim.

Teams brauchen Orientierung. Budgets brauchen Annahmen. Stakeholder brauchen Erwartbarkeit. Niemand kann ein Unternehmen, ein Produkt oder ein Projekt führen, wenn alles nur mit einem Schulterzucken beantwortet wird.

Das Problem beginnt nicht dort, wo jemand nach Planung fragt.

Das Problem beginnt dort, wo aus einer unsicheren Schätzung ein scheinbar belastbares Versprechen wird.

„Wir brauchen nur eine grobe Schätzung“

Der Satz klingt harmlos.

„Nur grob.“

„Nur für die Planung.“

„Nur damit wir ein Gefühl bekommen.“

Und dann passiert, was in Organisationen fast immer passiert.

Die grobe Schätzung wandert weiter.

Sie steht plötzlich in einer Roadmap. Dann in einer Budgetplanung. Dann in einem Steering. Dann in einer Erwartung. Dann in einer Eskalation.

Und irgendwann erinnert sich niemand mehr daran, dass diese Zahl unter Unsicherheit entstanden ist.

Aus „vielleicht zwei Wochen, wenn die Annahmen stimmen“ wird:

„Das Team hat zwei Wochen zugesagt.“

Das ist der Moment, in dem Planung kippt.

Nicht weil Management Planung braucht. Sondern weil Unsicherheit aus dem Plan entfernt wurde.

Softwareentwicklung ist keine Fließbandarbeit

Der Denkfehler hinter vielen Zeitschätzungen ist alt:

Man behandelt Softwareentwicklung wie deterministische Fertigung.

Als gäbe es einen bekannten Prozess. Als gäbe es bekannte Schritte. Als gäbe es bekannte Wiederholbarkeit. Als müsste man nur die Geschwindigkeit der Ausführung kennen.

Bei Fließbandarbeit ist das oft näher an der Wahrheit.

Wenn Material, Prozess, Werkzeug und Ziel bekannt sind, kann man Durchsatz messen. Dann wird Planung deutlich verlässlicher. Nicht perfekt, aber grundsätzlich beobachtbar.

Softwareentwicklung ist häufig etwas anderes.

Sie ist nicht nur Ausführung. Sie ist Analyse. Sie ist Modellierung. Sie ist Integration. Sie ist Fehlersuche. Sie ist fachliche Klärung. Sie ist Risikoreduktion. Sie ist die Entdeckung dessen, was man vorher nicht wusste.

Gerade in bestehenden Systemen ist die eigentliche Arbeit selten nur:

„Baue Feature X.“

Sondern eher:

„Finde heraus, was Feature X in diesem System überhaupt bedeutet, welche stillen Regeln existieren, welche Abhängigkeiten berührt werden und welche Annahmen falsch sind.“

Das ist keine Tippgeschwindigkeit.

Das ist Wissensarbeit unter Unsicherheit.

Erfahrung ist kein Röntgengerät

Ein besonders beliebter Satz lautet:

„Du bist doch Senior. Du kannst das doch schätzen.“

Ja.

Und nein.

Seniorität hilft.

Ein erfahrener Entwickler erkennt Muster schneller. Ein Architekt sieht Abhängigkeiten früher. Ein Tech Lead riecht Risiken, bevor sie im Daily stinken.

Aber Erfahrung ist kein Röntgengerät.

Sie zeigt nicht automatisch unbekannte Fachregeln. Sie zeigt nicht automatisch versteckte Seiteneffekte. Sie zeigt nicht automatisch historische Sonderfälle. Sie zeigt nicht automatisch kaputte Testdaten. Sie zeigt nicht automatisch, welche Altlast beim ersten echten Debugging aus der Wand fällt.

Gerade erfahrene Leute sind bei Schätzungen oft vorsichtiger, nicht weil sie weniger wissen, sondern weil sie mehr gesehen haben.

Der Junior sieht ein Ticket.

Der Senior sieht ein Ticket, drei implizite Annahmen, zwei unbekannte Schnittstellen, ein mögliches Berechtigungsthema, fehlende Testbarkeit und eine Fachfrage, die wahrscheinlich noch niemand entschieden hat.

Das ist keine Unsicherheit aus Schwäche.

Das ist Unsicherheit aus Systemverständnis.

Seniorität bedeutet nicht, Unsicherheit zu beseitigen. Seniorität bedeutet, Unsicherheit früher zu erkennen.

Die Forschung nennt das nicht Bauchgefühl

Dass Menschen Arbeit unterschätzen, ist kein neues Phänomen.

Die Psychologie kennt dafür den Begriff Planning Fallacy. Menschen neigen dazu, zukünftige Aufgaben optimistischer einzuschätzen, als es ähnliche vergangene Aufgaben rechtfertigen würden. Besonders gefährlich ist dabei die Innenperspektive: Man stellt sich vor, wie die Arbeit ideal läuft, und unterschätzt Störungen, Wartezeiten, Klärungen, Fehler und Abhängigkeiten.

In der Softwareentwicklung kommt noch etwas dazu.

Schätzungen entstehen oft durch Expert Judgment. Also durch Einschätzung erfahrener Menschen. Das ist nicht wertlos. Aber es ist anfällig für Optimismus, Anker, soziale Erwartungen und zu enge Unsicherheitsintervalle.

Wenn vorher ein Wunschdatum im Raum steht, ist die Schätzung nicht mehr neutral.

Wenn vorher Budgetdruck im Raum steht, ist die Schätzung nicht mehr neutral.

Wenn vorher jemand sagt „das ist doch nur eine kleine Änderung“, ist die Schätzung nicht mehr neutral.

Dann wird nicht nur geschätzt.

Dann wird verhandelt.

Und oft wird nicht einmal offen verhandelt. Die Zahl wird nur psychologisch in die gewünschte Richtung gezogen.

Der Cone of Uncertainty ist keine Ausrede

Der Cone of Uncertainty beschreibt eine einfache, unangenehme Wahrheit:

Frühe Schätzungen sind unsicherer als spätere Schätzungen.

Nicht weil frühe Schätzer unfähig sind.

Sondern weil am Anfang Informationen fehlen.

Anforderungen sind noch unklar. Schnittstellen sind noch nicht getestet. Risiken sind noch nicht sichtbar. Fachregeln sind noch nicht explizit. Abhängigkeiten sind noch nicht erlebt. Technische Schulden sind noch nicht berührt.

Man kann in dieser Phase trotzdem planen.

Aber man sollte nicht so tun, als wäre eine frühe Zahl genauso belastbar wie eine Prognose nach mehreren echten Slices, Integrationen und Feedbackzyklen.

Eine frühe Schätzung ist keine Wahrheit.

Sie ist der aktuelle Stand der Unwissenheit.

Das klingt hart.

Ist aber hilfreich.

Denn sobald man das akzeptiert, kann man etwas Vernünftiges tun: die Unwissenheit reduzieren.

„It’s done when it’s done“ ist ehrlich, aber unbrauchbar

Manchmal ist die ehrlichste innere Antwort:

„Keine Ahnung. Fertig ist es, wenn es fertig ist.“

Das ist menschlich.

Gerade in einem neuen System. Mit neuer Fachlichkeit. Mit unbekannter Architektur. Mit unbekannten Daten. Mit unbekannten Abhängigkeiten.

Aber als Antwort hilft es niemandem.

Nicht dem Management. Nicht dem Team. Nicht dem Kunden. Nicht der Planung.

Die professionellere Antwort lautet:

„Für eine belastbare Zeitschätzung fehlt aktuell System- und Fachwissen. Ich kann aber die nächsten Schritte schätzen, mit denen wir diese Unsicherheit reduzieren.“

Das ist ein wichtiger Unterschied.

Man verweigert nicht Planung.

Man plant nicht das unbekannte Ergebnis.

Man plant den nächsten Erkenntnisschritt.

Zum Beispiel:

• einen technischen Spike
• eine Analyse der betroffenen Schnittstellen
• ein minimales End-to-End-Slice
• eine fachliche Klärung mit konkreten Beispielen
• eine Charakterisierung des bestehenden Verhaltens
• einen Prototyp gegen echte Daten
• eine Risikoentscheidung vor der Umsetzung

Das ist erwachsene Planung.

Nicht:

„Wir wissen schon, wann alles fertig ist.“

Sondern:

„Wir wissen, was wir als Nächstes herausfinden müssen, um besser planen zu können.“

Wenn Schätzungen Menschen sortieren

Ein kleines Beispiel.

Ein Ticket wird im Team geschätzt.

Ein Junior sagt:

„Fünf Tage.“

Ein Senior sagt:

„Ein Tag.“

Nach Diskussion einigt sich das Team auf:

„Zwei Tage.“

Dann kommt die scheinbar praktische Frage:

„Wer macht es?“

Und wenn die Antwort lautet:

„Dann natürlich der Senior“,

ist etwas kaputt.

Denn dann wurde nicht Arbeit geschätzt.

Dann wurden Menschen sortiert.

Die Schätzung ist nicht mehr Ausdruck der Teamkomplexität. Sie wird zur verdeckten Vorab-Zuweisung.

Das hat Folgen.

Der Junior lernt nicht. Der Senior wird Engpass. Wissen konzentriert sich weiter. Das Team wird abhängiger von einzelnen Personen. Komplexe Arbeit landet immer bei denselben Leuten. Senioren brennen aus. Junioren bleiben länger Junioren. Selbstorganisation wird zur Fassade.

Kurzfristig sieht das effizient aus.

Langfristig baut man ein System, in dem die erfahrensten Menschen permanent die schwierigsten Aufgaben retten müssen, während niemand sonst genug Raum bekommt, daran zu wachsen.

Das ist keine agile Planung.

Das ist Kapazitätsverwaltung mit Lernverhinderung.

Goodhart wartet schon im Jira

Schätzungen haben noch ein anderes Problem.

Sobald eine Kennzahl zur Zielgröße wird, verändert sich das Verhalten um diese Kennzahl herum.

Das ist als Goodhart’s Law bekannt:

Wenn ein Maß zur Zielgröße wird, hört es auf, ein gutes Maß zu sein.

Auf Software übertragen:

Wenn geschätzte Stunden zur Steuerungsgröße werden, optimiert das System auf geschätzte Stunden.

Nicht auf Wert. Nicht auf Lernen. Nicht auf Qualität. Nicht auf Risikoreduktion. Nicht auf echte Lieferfähigkeit.

Sondern auf die Zahl.

Ein Beispiel:

Ein Entwickler schätzt ein Ticket auf 40 Stunden.

Nach 20 Stunden ist er fertig.

Was passiert jetzt?

In einem gesunden System wäre das eine gute Nachricht.

Die Arbeit war kleiner als gedacht. Es gibt neue Information. Die Prognose kann besser werden. Vielleicht war das Ticket einfacher. Vielleicht war die Lösung eleganter. Vielleicht war die Schätzung zu defensiv. Vielleicht wurde Risiko früh reduziert.

In einem kaputten System entsteht ein anderer Impuls:

„Buche lieber 40 Stunden, sonst sieht die nächste Schätzung schlecht aus.“

Oder:

„Wenn ich ehrlich 20 Stunden buche, wird beim nächsten Mal erwartet, dass es wieder 20 sind.“

Oder:

„Wenn ich schneller fertig bin, bekomme ich nur mehr Arbeit.“

Oder:

„Wenn wir unter Plan liefern, wird der Plan beim nächsten Mal aggressiver.“

Damit wird die Schätzung zur selbsterfüllenden Prophezeiung.

Nicht weil Entwickler faul sind.

Sondern weil das System falsche Anreize setzt.

Wer Schätzungen als persönliche Leistungskennzahl verwendet, schützt nicht die Planung.

Er zerstört die Daten, die Planung überhaupt verbessern könnten.

Dann sind gebuchte Stunden keine Beobachtung mehr.

Sie sind Verteidigung.

Scheingenauigkeit fühlt sich besser an als Unsicherheit

Warum passiert das trotzdem?

Weil Scheingenauigkeit beruhigt.

„Das dauert 17 Tage“ klingt besser als:

„Zwischen 8 und 30 Tagen, abhängig davon, ob die Schnittstelle tut, was dokumentiert ist.“

Eine einzelne Zahl passt besser in eine Roadmap. Eine einzelne Zahl passt besser in ein Budget. Eine einzelne Zahl passt besser in eine PowerPoint. Eine einzelne Zahl passt besser in ein Gespräch mit Menschen, die keine Unsicherheit hören wollen.

Aber eine einzelne Zahl ist nicht automatisch genauer.

Sie ist nur leichter zu konsumieren.

Und genau das ist gefährlich.

Denn Unsicherheit verschwindet nicht, wenn man sie aus der Folie löscht.

Sie taucht später wieder auf.

Als Verzögerung. Als Bug. Als Rework. Als Eskalation. Als Wochenendarbeit. Als „Warum habt ihr das nicht früher gesagt?“

Die Antwort ist oft:

Haben wir. Nur nicht in einer Form, die in den Plan durfte.

Was hilft wirklich?

Die Alternative zu schlechten Zeitschätzungen ist nicht planloses Arbeiten.

Die Alternative ist bessere Planung.

Und bessere Planung beginnt damit, Unsicherheit nicht zu verstecken, sondern aktiv zu reduzieren.

1. Kleine Arbeitspakete schneiden

Je größer ein Ticket ist, desto stärker dominieren unbekannte Risiken.

Wenn ein Ticket grob länger als drei Entwicklungstage wirkt, ist das kein Naturgesetz, aber ein Warnsignal.

Vielleicht ist das Ticket zu groß. Vielleicht enthält es mehrere Entscheidungen. Vielleicht sind Analyse und Umsetzung vermischt. Vielleicht fehlt ein fachliches Beispiel. Vielleicht hängt es an einer unbekannten Schnittstelle. Vielleicht ist es eigentlich ein Projekt in Verkleidung.

Kleine Tickets machen nicht automatisch alles einfach.

Aber sie machen Abweichungen kleiner.

Und kleine Abweichungen sind planbar.

2. Komplexität statt Stunden schätzen

Relative Komplexität ist oft ehrlicher als Stundenraten.

Nicht:

„Das dauert 13 Stunden.“

Sondern:

„Das ist klein, bekannt und risikoarm.“

Oder:

„Das ist fachlich unklar, technisch gekoppelt und sollte zuerst geschnitten werden.“

Story Points, T-Shirt-Sizes oder ähnliche Modelle sind keine Magie.

Sie funktionieren nur, wenn sie nicht heimlich wieder in Stunden zurückübersetzt werden.

Sobald aus „5 Punkte“ automatisch „3 Tage“ wird, hat man nur eine neue Währung für alte Scheingenauigkeit erfunden.

3. Unsicherheit explizit machen

Eine brauchbare Schätzung besteht nicht nur aus einer Zahl.

Sie braucht Kontext.

Zum Beispiel:

• optimistisch
• wahrscheinlich
• pessimistisch
• größte Annahme
• größtes Risiko
• offene Entscheidung
• Abhängigkeit
• nächster Erkenntnisschritt

Eine Aussage wie:

„Wahrscheinlich zwei bis vier Tage, aber nur wenn die vorhandene API die erwarteten Daten liefert. Das größte Risiko ist die Berechtigungslogik.“

ist für Planung deutlich wertvoller als:

„Drei Tage.“

Auch wenn sie unbequemer ist.

4. Erst Risiken reduzieren, dann Termine fixieren

Wenn ein Vorhaben groß, unklar oder fachlich neu ist, sollte man nicht sofort die Gesamtumsetzung schätzen.

Man sollte zuerst den riskantesten Teil angreifen.

Nicht den einfachsten.

Nicht den hübschesten.

Nicht den Teil, der in der Demo gut aussieht.

Sondern den Teil, der die Planung am stärksten gefährdet.

Das kann eine Schnittstelle sein. Ein Berechtigungskonzept. Ein Datenmodell. Eine Migration. Ein fachlicher Sonderfall. Ein Performance-Risiko. Ein Deployment-Pfad. Ein Testbarkeitsproblem.

Planungssicherheit entsteht, wenn die größten unbekannten Risiken kleiner werden.

Nicht wenn jemand länger auf eine Zahl starrt.

5. Historische Daten verwenden

Wenn man Planung verbessern will, braucht man echte Beobachtung.

Nicht als Kontrollinstrument gegen einzelne Personen.

Sondern als Außenperspektive für das Team.

Wie lange brauchen ähnliche Tickets wirklich? Wie oft blockieren externe Abhängigkeiten? Wie groß ist unsere Cycle Time? Wie viele Items schaffen wir stabil? Welche Arbeitstypen explodieren regelmäßig? Wo entsteht Rework? Wo warten Tickets? Wo fehlt Entscheidungsfähigkeit?

Das ist der Punkt, an dem Planung erwachsen wird.

Weg von:

„Was glaubt ihr, wie lange das dauert?“

Hin zu:

„Was zeigen unsere echten Durchlaufzeiten für ähnliche Arbeit?“

6. PERT als Denkwerkzeug nutzen, nicht als Wahrheitsmaschine

PERT und Drei-Punkt-Schätzungen können helfen, Unsicherheit sichtbar zu machen:

• optimistisch
• wahrscheinlich
• pessimistisch

Das ist besser als eine einzelne Zahl.

Aber auch PERT wird falsch, wenn am Ende wieder nur eine scheinbar exakte Zahl herausfällt, die dann als Zusage behandelt wird.

PERT hilft vor allem dann, wenn viele unabhängige Aufgaben sich statistisch mitteln können.

Bei wenigen großen, gekoppelten Risiken hilft keine schöne Formel.

Dann braucht man kleinere Slices.

Planungssicherheit ist Risikomanagement

Planungssicherheit entsteht nicht dadurch, dass man Menschen härter nach Daten fragt, die sie noch nicht seriös wissen können.

Sie entsteht dadurch, dass man Arbeit so strukturiert, dass Unsicherheit früher sichtbar und kleiner wird.

Das bedeutet:

• kleinere Tickets
• echte fachliche Beispiele
• frühe technische Durchstiche
• klare Schnittgrenzen
• schnelle Feedbackzyklen
• sichtbare Risiken
• ehrliche Spannweiten
• historische Durchlaufzeiten
• regelmäßige Aktualisierung der Prognose

Das ist weniger bequem als eine Zahl.

Aber deutlich nützlicher.

Der bessere Satz

Die Frage sollte nicht lauten:

„Wie lange dauert das?“

Zumindest nicht als erste Frage.

Die besseren Fragen lauten:

„Was wissen wir sicher?“ „Was ist noch Annahme?“ „Was ist das größte Risiko?“ „Wie schneiden wir es kleiner?“ „Was können wir diese Woche lernen?“ „Welche echte Beobachtung verbessert unsere Prognose?“

Denn eine Schätzung ist kein Lieferdatum.

Sie ist eine Aussage über den aktuellen Stand unserer Unsicherheit.

Management braucht Planung.

Aber Planung braucht Unsicherheit, nicht Scheingenauigkeit.

Und wer wirklich Planungssicherheit will, fordert nicht bessere Fantasiezahlen.

Er baut ein System, das Risiken früher sichtbar macht.