Warum Schätzungen scheitern (und warum sie trotzdem notwendig sind)

• In der Softwareentwicklung gehört die Aufwandsschätzung in den Complex-Bereich und ist selbst für sehr erfahrene Teams grundsätzlich nicht präzise möglich
• Die #NoEstimates-Bewegung war eine berechtigte Gegenreaktion auf die Realität, dass Schätzungen als Leistungsziel missbraucht werden, aber wenn man Schätzungen selbst ablehnt, verliert die Organisation ihre Fähigkeit zur Abstimmung
• Der zentrale Wert von Schätzungen liegt nicht in der Vorhersage der Zukunft, sondern in Kommunikation und Abstimmung unter Unsicherheit; sie sind unverzichtbar für externe Verträge, teamübergreifende Abhängigkeiten und ROI-Entscheidungen
• Laut Steve McConnells Cone of Uncertainty können Schätzfehler zu Beginn eines Projekts um den Faktor 4 auftreten; kleiner wird die Spanne nur durch Lernen
• Man muss die organisatorische Gewohnheit ändern, Schätzungen in Zusagen zu verwandeln, und einen Schätzansatz mit Spannen, expliziten Annahmen und schrittweiser Kalibrierung einführen

---

Welches Problem die #NoEstimates-Bewegung tatsächlich gelöst hat

• Teams werden immer wieder um Schätzungen gebeten, obwohl sie über das Problem fast nichts wissen, und diese Zahlen landen dann auf der Roadmap und werden Kunden gegenüber als Zusagen dargestellt
• Wenn die Realität von der Schätzung abweicht, wird dem Team vorgeworfen, es habe „die Deadline verpasst“, obwohl diese Deadline nie gemeinsam vereinbart wurde
• Das zentrale pathologische Muster ist, dass Schätzungen nicht als Vorhersage, sondern als Commitment behandelt werden
• Die Lösung „Lasst uns nicht schätzen“ ist wie die Reaktion auf ein kaputtes Thermometer, bei der man das Konzept Temperatur selbst leugnet
• Wie Maarten Dalmijn es formuliert: Schätzungen ändern den tatsächlichen Arbeitsaufwand nicht; Feature-Entwicklung dauert so lange, wie sie eben dauert
  • Was Schätzungen beeinflussen, ist nicht die Arbeit selbst, sondern die Erwartungen darum herum
  • Diese Erwartungen ehrlich und klar zu steuern, ist absolut lohnende Arbeit

Warum Organisationen Schätzungen tatsächlich brauchen

• Ein Punkt, der in der #NoEstimates-Debatte fast immer fehlt: Schätzungen sind nicht für das Team da, das die Arbeit ausführt, sondern für die Organisation um dieses Team herum

• Es gibt drei Situationen, in denen Schätzungen unvermeidlich sind

• Externe Zusagen: Bei Kundenverträgen, Releases in Verbindung mit Marketingkampagnen oder regulatorischen Deadlines ist ein Modell für den benötigten Aufwand unverzichtbar, um die Machbarkeit beurteilen zu können

  • „Wir schätzen nicht“ ist keine Antwort, die man Kunden geben kann, und kann zum Vertragsverlust führen

• Teamübergreifende Abhängigkeiten: Wenn Team B auf den Abschluss von Team A warten muss, kann Team B nicht planen, wenn Team A keinerlei Prognose liefert

  • Ein grobes Signal („wahrscheinlich 6 Wochen, höchstens 8“) ist unendlich viel nützlicher als Schweigen; das ist keine Kontrolle, sondern Respekt gegenüber nachgelagerten Teams

• ROI-Berechnung: Wer entscheiden will, ob Feature X oder Feature Y gebaut werden soll, braucht ein Modell der relativen Kosten

  • Wenn alles unknowable ist, sind rationale Trade-offs unmöglich; und wenn man ohnehin rät, dann besser als strukturierte Schätzung mit expliziten Annahmen

Joseph Pelrine zeigt die inhärente Schwierigkeit von Schätzungen

• Joseph Pelrine ist Europas erster Certified Scrum Trainer und untersucht agile Softwareentwicklung durch die Linse der sozialen Komplexitätswissenschaft
• Er führte mit mehr als 300 Personen aus der agilen Softwareentwicklung ein Experiment durch, bei dem Alltagsaktivitäten anhand des Cynefin-Frameworks (Dave Snowdens Sensemaking-Modell) in Domänen eingeordnet wurden
  • Cynefin unterteilt Probleme in die vier Bereiche Clear, Complicated, Complex und Chaotic
• Aufwandsschätzung wurde konsistent und wiederholt dem Complex-Bereich zugeordnet
• Entscheidend ist der Unterschied zwischen Complicated und Complex:
  • Im Complicated-Bereich lassen sich Ursache-Wirkungs-Beziehungen erkennen, von Expertinnen und Experten nachverfolgen, und Fachwissen erzeugt verlässliche Prognosen
  • Im Complex-Bereich lassen sich Ursache-Wirkungs-Beziehungen erst im Nachhinein erkennen; das System ist zu verflochten, kontextabhängig und empfindlich gegenüber kleinen Veränderungen
• Deshalb ist Softwareentwicklung keine Fertigung: Man baut fast immer etwas, das es vorher nicht gab, auf einer einzigartigen Codebasis mit eigener Teamdynamik
  • Deshalb trägt auch der Tischler-Vergleich nicht: Schränke ähneln sich grob, aber Features ähneln sich nicht grob
• Selbst herausragende Teams schaffen nur durchschnittlich gute Schätzungen, nicht wegen mangelnder Fähigkeiten, sondern weil die Genauigkeit im Complex-Bereich grundsätzlich begrenzt ist
• Das Ziel ist nicht, „richtig zu schätzen“, sondern trotz inhärenter Ungenauigkeit nützliche Entscheidungen zu treffen

Was der Cone of Uncertainty aussagt

• Steve McConnells Konzept des Cone of Uncertainty: Zu Beginn eines Projekts können Schätzfehler in beide Richtungen um den Faktor 4 auftreten, also insgesamt über eine 16-fache Spannweite
• Während das Projekt voranschreitet und Unbekanntes aufgelöst wird — Anforderungen werden klarer, Architekturentscheidungen fallen, schwierige Probleme werden entdeckt und gelöst — verengt sich der Kegel
• Die Ironie: Am genauesten werden Schätzungen kurz vor dem Abschluss, also genau dann, wenn sie am wenigsten gebraucht werden
  • In der frühen Phase, in der sie am nützlichsten wären — wenn man noch umsteuern oder das Projekt stoppen kann — weiß man am wenigsten
  • Und genau in dieser frühen Phase geben die meisten Organisationen die verbindlichsten Zusagen
• Zwei weitere Implikationen:
  • Der Kegel beschreibt den Best Case für erfahrene Schätzerinnen und Schätzer; die meisten Teams liegen darunter
  • Schon in der Konzeptphase ein Datum festzulegen, ist keine Planung, sondern Wunschdenken mit Termin dahinter
  • Der Kegel wird nicht durch Zeit, sondern nur durch Entscheidungen kleiner, die Unsicherheit abbauen
  • Scope-Definition, das Auflösen architektonischer Unbekannter sowie reales Coding und das Entdecken von Hürden verengen den Kegel; drei Wochen Meetings allein tun das nicht
• Gegenüber Stakeholdern sollte explizit kommuniziert werden: „Die Qualität einer Schätzung hängt davon ab, wo wir uns im Kegel befinden“
  • In Woche 1 kann man keine Zahl liefern, die die Sicherheit einer 2-Wochen-Schätzung hat; man kann aber eine Spanne nennen und erklären, was geklärt werden muss, um sie zu verengen
  • Die meisten Stakeholder akzeptieren das, wenn man den Kegel erklärt; niemand hat ihnen je gesagt, dass man auch nach einer Spanne fragen darf

Warum die Fibonacci-Skala verwendet wird

• Die Nichtlinearität der Fibonacci-Skala (1, 2, 3, 5, 8, 13, 21) erfüllt eine epistemische Funktion
• Der Unterschied zwischen 2 und 3 ist nur ein „grober Unterschied“, aber der Sprung von 8 auf 13 codiert, dass das Unsicherheitsband breiter ist als der Schätzwert selbst
  • Eine 13-Punkte-Story bedeutet nicht „exakt 13“, sondern „klar unsicherer als 8, aber nicht so groß wie 21“
• Die Abstände zwischen den Fibonacci-Zahlen spiegeln wider, wie Komplexität tatsächlich skaliert
  • Kleine Dinge lassen sich grob schätzen, große Dinge sind wegen unbekannter Faktoren, Integrationspunkten und Überraschungen exponentiell schwerer vorherzusagen
  • Stories mit 21 Punkten (oder auch 13) bedeuten: „Wir verstehen die Arbeit noch nicht genug und müssen sie aufteilen“
• Eine weitere unterschätzte Funktion von Fibonacci-Schätzungen ist, was im Gespräch während des Schätzens passiert
  • Wenn eine Person 3 sagt und eine andere 13, ist die Zahl selbst fast egal; wichtig ist, warum dasselbe Team dieselbe Story so unterschiedlich sieht
  • Vielleicht hat eine Seite eine Abhängigkeit entdeckt oder kennt technische Einschränkungen, die nicht im Ticket stehen
• Der größte Wert von Schätzungen liegt nicht in der Zahl, sondern darin zu prüfen, ob ein gemeinsames Verständnis entstanden ist
  • Wenn man diesen Mechanismus entfernt, entsteht gemeinsames Verständnis oft erst dann, wenn jemand am dritten Arbeitstag auf versteckte Komplexität stößt
• Deshalb ist der #NoEstimates-Einwand „Schätzmeetings sind Verschwendung“ schwer zu akzeptieren: Wenn sie gut moderiert sind, entsteht in diesem Gespräch Alignment
  • Die Antwort auf schlecht geführte Meetings ist nicht, Meetings abzuschaffen

Die Commitment Trap und wie man sie vermeidet

• Die tiefste Dysfunktion, auf die die #NoEstimates-Bewegung reagierte, ist: Schätzungen werden nicht durch Logik, sondern durch sozialen Druck in Commitments verwandelt
• Ein typischer Failure Mode: Menschen, die die Arbeit nicht ausführen, erstellen eine Timeline und reichen sie ans Team weiter — die schlimmste Kombination aus ungenauer Schätzung + Team ohne Ownership für die Zahl
  • Wenn die Realität abweicht, weiß niemand, wer verantwortlich ist, also geben sich am Ende alle gegenseitig die Schuld
  • Die Menschen, die die Arbeit tatsächlich erledigen, müssen die Schätzung immer selbst verantworten; anderen Schätzungen aufzuzwingen ist kein Optimismus, sondern das Vorspiel zum Blame Game
• Sobald Deadlines zur Obsession werden, läuft jedes Gespräch auf „Wie halten wir die Deadline ein?“ hinaus, und die Frage, ob wir überhaupt das Richtige bauen, verschwindet aus dem Blick
• Organisationen müssen drei Dinge trennen, die sie meist verwechseln:
  1. Schätzung (Estimate): eine probabilistische Vorhersage auf Basis des aktuellen Unsicherheitsniveaus, mit expliziter Angabe von Spanne und Annahmen
     • Beispiel: „Wir gehen von 4 bis 6 Wochen aus, vorausgesetzt, die Anforderungen ändern sich nicht und wir bekommen bis nächsten Freitag Antworten auf die API-Fragen.“
  2. Plan: eine Zusage zum Prozess, nicht zum Ergebnis
     • Beispiel: „Wir arbeiten zwei Wochen daran, prüfen dann den Fortschritt und liefern eine aktualisierte Prognose.“
  3. Commitment: eine Zusage zum Ergebnis; sie sollte selten und nur dann abgegeben werden, wenn der Kegel bereits ausreichend eng geworden ist
     • Ein Commitment in der frühen Konzeptphase ist nicht mutig, sondern leichtsinnig
     • Wenn man zu einem Commitment gedrängt wird, sollte man möglichst kein Datum, sondern eine Priorität zusagen; und wenn selbst das nicht geht, dann das Vertrauensniveau als Teil des Commitments festhalten
• Die eigentliche Ursache der Dysfunktion ist die organisatorische Praxis, eine Schätzung in dem Moment, in dem sie ausgesprochen wird, als Commitment zu behandeln
  • Die politische Lösung von #NoEstimates — überhaupt keine Zahlen mehr zu nennen — ist verständlich, kostet die Organisation aber die Fähigkeit, Ressourcen zuzuweisen, Abhängigkeiten zu priorisieren und ehrliche Gespräche mit externen Stakeholdern zu führen
• Die bessere Lösung ist, den Cone of Uncertainty zu vermitteln, Stakeholder zu schulen und bei jeder Zahl den Unterschied zwischen Schätzung und Commitment klar zu benennen
  • Das ist schwieriger und dauert länger als Schätzungen komplett abzulehnen, aber statt Situationen zu vermeiden, in denen Vertrauen brechen kann, baut es Vertrauen auf

Gute Praktiken für Schätzungen

• Spät schätzen: Der Kegel wird nur durch Lernen kleiner; deshalb zuerst Spikes durchführen, explorativen Code schreiben oder mit Teams sprechen, von denen Integrationen abhängen
  • Dem Druck, Zahlen zu liefern, bevor genug gelernt wurde, um sinnvolle Zahlen nennen zu können, muss man widerstehen
• Vor dem Start nicht übermäßig zerlegen: Unter Unsicherheit will man Arbeit intuitiv in immer kleinere Stücke zerlegen, aber hinreichend feine Aufteilung erzeugt noch keine verlässliche Schätzung
  • Ausgefeilte Vorabplanung verfestigt sich leicht, sodass Teams an einem Plan festhalten, der die Realität längst nicht mehr abbildet; dadurch wird die spätere Abweichung nur noch verwirrender
  • Besser ist ein einfacher Plan, der leicht angepasst werden kann
• Spannen statt Punktschätzungen liefern: „3 bis 5 Wochen“ ist ehrlicher als „4 Wochen“ und fast genauso gut handhabbar
  • Wenn unbedingt nur eine Zahl akzeptiert wird, dann den Mittelwert der Spanne nennen — aber ausdrücklich als Mittelwert kennzeichnen
  • Mit Stakeholdern die Nutzung des Cone of Uncertainty vereinbaren und bei jeder Schätzung darauf verweisen
• Annahmen sichtbar machen: Eine Schätzung ist nur so gut wie ihre Annahmen; also Scope-Stabilität, einen bestimmten technischen Ansatz oder Liefertermine anderer Teams explizit benennen
  • Annahmen, die nur im Kopf existieren, werden im schlechtesten Moment zu Missverständnissen
• Genauigkeit verfolgen, aber nicht bestrafen: Das Ziel ist Kalibrierung, nicht Schuldzuweisung
  • Teams, die sechs Monate lang gemeinsam schätzen und ihre Genauigkeit überprüfen, entwickeln systematisch ein gemeinsames Gefühl dafür, wo sie über- oder unterschätzen
  • Wer ungenaue Schätzungen bestraft, bringt Teams dazu, defensiv nach oben zu puffern; und aufgeblähte Schätzungen sind noch weniger nützlich als ehrliche, aber unsichere Schätzungen
  • Falsche Schätzungen im Complex-Bereich sind kein Charakterfehler, sondern eine Eigenschaft des Bereichs
• Über 8 aufteilen: Fibonacci-Stories mit 13 oder 21 Punkten enthalten fast immer versteckte Komplexität, die noch nicht sichtbar geworden ist
  • Das Aufteilen zwingt dazu, klarer auszudrücken, was man tatsächlich schon weiß
  • Oft stellt sich heraus, dass zwei von drei Teil-Stories klein sind und sich die gesamte Unsicherheit auf eine einzige konzentriert

Die unbequeme Wahrheit für beide Lager

• Schätzungen sind keine Berechnung, sondern eine Form von Kommunikation; ihr Zweck ist nicht die Zukunft exakt vorherzusagen, sondern Abstimmung und Entscheidungsfindung unter Unsicherheit zu unterstützen
• Die Failure Modes von Schätzungen sind nicht zufällig, sondern systematisch: zu frühes Schätzen, Spannen als Punkte behandeln, Schätzungen als Commitments behandeln, die epistemische Position im Cone of Uncertainty ignorieren und Ausführenden Schätzungen aufzwingen
• Was Dalmijn als Complex Work Estimation Fallacy bezeichnet: der Glaube, dass häufigeres Schätzen, Prozessverbesserungen und längere Zusammenarbeit am Ende zu präzisen Schätzungen führen
  • Im Complex-Bereich ist die Grenze der Schätzgenauigkeit keine Funktion der Teamreife, sondern eine Funktion des Bereichs selbst
  • Man kann besser werden, aber nicht präzise; wer beides verwechselt, bringt Organisationen dazu, Teams für Dinge zu bestrafen, die grundsätzlich außerhalb ihrer Kontrolle liegen
• Schätzungen abzulehnen ist letztlich nur der Ausstieg aus dem Spiel der Abstimmung
  • Das mag in vollständig unabhängigen Setups mit Continuous Deployment und ohne externe Zusagen funktionieren, aber in den meisten Karrieren ist das nicht der Normalfall
• Die Wahl lautet nicht „schlechte Schätzungen“ versus „keine Schätzungen“, sondern zwischen impliziten, minderwertigen Schätzungen — die die Organisation ohnehin auch ohne dich produziert — und expliziten, demütigen, spannengestützten Schätzungen mit sichtbaren Annahmen
• Weil Aufwandsschätzung im Complex-Bereich liegt, muss man sie mit einem Komplexitäts-Mindset angehen: erkunden, beobachten, reagieren, schätzen, verfolgen, kalibrieren — in Schleifen
• Der Kegel wird nicht durch Warten kleiner, sondern durch Lernen