Schätzung ist eines der umstrittensten Themen in Agile-Gemeinschaften. Die Argumente verlaufen gewöhnlich so: Story Points versus Stunden, relatives versus absolutes Sizing, #NoEstimates versus einige Schätzungen, Planning Poker versus was auch immer danach kam.
Das sind echte Debatten. Und sie neigen dazu, das tiefere Problem zu übersehen — nämlich dass die Argumente darüber, wie man schätzt, als Ersatz für ein Gespräch darüber stehen, ob das Schätzmodell selbst das Problem ist.
Was Agile über Schätzung wirklich sagte
Agile entstand nicht, um Teams bei besseren Schätzungen zu helfen. Es entstand, weil jemand bemerkte, dass bei komplexer Arbeit — Arbeit, bei der die vollständigen Anforderungen nicht im Voraus bekannt sein können, bei der sich der richtige Ansatz durch das Tun offenbart — die Präzision, die Schätzung verspricht, falsche Präzision ist.
Was “komplexe Arbeit” wirklich bedeutet
Diese Phrase — komplexe Arbeit, Arbeit, bei der die vollständigen Anforderungen nicht im Voraus bekannt sein können — ist leicht zu überlesen. Das sollte sie nicht sein. Es ist die strukturell wichtigste Behauptung in diesem Beitrag, und ohne sie zu verinnerlichen, kann alles Folgende als Argument über Schätztechniken und nicht über die Eignung der Schätzung für den Zweck gehört werden.
Komplexe Arbeit ist keine Beschreibung von Projekten, bei denen das Team nicht klug genug war, oder nicht rigoros genug, oder bei denen die richtige Methodik noch nicht angewendet worden war. Sie benennt eine bestimmte Kategorie: Arbeit, bei der die Beziehung zwischen Ursache und Wirkung nur rückblickend verstanden werden kann. Wo sich der richtige Ansatz durch das Tun offenbart, nicht durch Analyse. Wo sich Anforderungen ändern, nicht weil die Stakeholder es versäumt haben, im Voraus sorgfältig zu denken, sondern weil das Tun der Arbeit ändert, was gebraucht wird.
Methodologien — auch ausgezeichnete — sind für einfache und komplizierte Arbeit gebaut. Sie funktionieren, indem sie bekannte Muster auf bekannte Problemtypen anwenden. Das ist genau ihr Wert in den Kontexten, für die sie konzipiert wurden. Komplexe Arbeit hat keine bekannten Muster. Sie hat emergente. Das Anwenden einer Methodologie auf komplexe Arbeit löst das Problem nicht — es erzeugt die Illusion von Struktur, während die eigentliche Unsicherheit unberührt bleibt. Mini-Wasserfälle — die kurzzyklige sequentielle Planung, zu der viele Agile-Implementierungen still und leise wurden — fallen in dieselbe Kategorie. Die Iterationslänge ändert sich; die zugrundeliegende Annahme, dass vorausschauende Planung die Arbeit zuverlässig leiten kann, tut es nicht.
“Rücksichtslose Vereinfachung” ist eine verwandte Empfehlung, die es wert ist, untersucht zu werden. Wenn Arbeit wirklich auf einen bekannten Problemtyp vereinfacht werden kann, vereinfachen Sie sie — das ist gute Praxis. Aber es ist Hygiene, keine Verwaltung komplexer Arbeit. Was nach aller möglichen Vereinfachung übrig bleibt, ist der Teil, der ihr widersteht, das ist die komplexe Arbeit selbst, die etwas erfordert, wofür Vereinfachungsstrategien nicht konzipiert sind. Im Jahr 2025, wenn die wettbewerbliche Reaktion auf Komplexität “wir sollten mehr vereinfachen” lautet, hat das Gespräch über die tatsächliche Verwaltung komplexer Arbeit noch nicht begonnen.
Jeffries’ öffentliche Umkehr ist nicht nur eine Meinungsänderung über eine Messeinheit. Es ist die Anerkennung von etwas Tieferem: Die Prämisse war falsch. Schätzung setzt eine Kategorie von Arbeit voraus, bei der vorausschauende Analyse zuverlässige Prognosen liefert. Für einfache und komplizierte Arbeit hält diese Annahme einigermaßen gut. Für komplexe Arbeit hält sie nicht — und keine Verfeinerung der Technik wird sie halten lassen. Diese Erkenntnis, einmal verinnerlicht, verändert, worum es im Rest dieses Beitrags geht.
Ein zweiwöchiger Sprint, der funktionierende Software liefert, ist keine bessere Schätzmethode. Es ist ein Ersatz für Schätzung durch empirische Messung. Anstatt vorherzusagen, wie lange die Arbeit dauern wird, messen Sie, wie viel tatsächlich erledigt wird, unter realen Bedingungen, in realen Inkrementen. Die Vorhersage wird durch eine Kadenz und eine Feedbackschleife ersetzt.
Das ist keine subtile Unterscheidung. Es bedeutet, dass Teams, die Agile-Prozesse ausführen, aber immer noch die genaue Story-Point-Schätzung als Ziel behandeln, grundlegend missverstanden haben, wofür der Prozess ist.
Warum die Argumente anhalten
Die Schätzdebatte hält an, teilweise weil die Organisationen, die Agile adoptierten, ihren zugrundeliegenden Bedarf nicht aufgaben: Managementsysteme, die auf Prognosen, Budgets, Zeitplänen, Verträgen basieren. Agile-Zeremonien wurden auf diesen Bedarf aufgeschichtet. Story Points wurden zu einem Ersatz für Stunden. Velocity wurde zu einem Planungsinput. Das Agile-Vokabular wurde übernommen; die Prognoseerwartung wurde nicht verworfen.
Die resultierende Situation ist wirklich umstritten. Einige Teams operieren in Umgebungen, wo “keine Schätzungen” wirklich möglich ist — wo Stakeholder gelernt haben, empirischer Lieferung zu vertrauen und keine Prognosen brauchen. Andere Teams operieren in Umgebungen, wo Verträge, regulatorische Anforderungen oder die Organisationskultur irgendeine Form von Prognose unvermeidlich machen.
Die Agile-Position ist nicht, dass Schätzung immer falsch ist. Es ist, dass Schätzung bei komplexer Arbeit strukturell unzuverlässig ist — dass das mit Schätzungen verbundene Vertrauen regelmäßig die Beweise dafür übersteigt — und dass die Disziplin kurzer Lieferzyklen mit echtem Feedback mehr tut, um die Vorhersagbarkeit zu verbessern als bessere Schätzmethoden.
Das Einheitenproblem — und ein Muster, das es wert ist, bemerkt zu werden
Ein aktueller Trend in Agile-Kreisen ist die Abkehr von Story Points hin zu Ideale Personentage (IPDs) — eine Rückkehr zur zeitbasierten Schätzung, die ihre Befürworter als intuitiver und leichter gegenüber Stakeholdern zu verteidigen argumentieren.
Es lohnt sich zu wissen, woher Story Points stammen. Ron Jeffries — einer der drei Gründer von Extreme Programming und ursprünglicher Unterzeichner des Agile Manifests — erfand Story Points. Sie entstanden direkt aus Ideal Days, der zeitbasierten Einheit, die XP-Teams ursprünglich verwendeten. Das Problem mit Ideal Days war, dass Stakeholder “drei Ideal Days” hörten und das als Drei-Tage-Commitment interpretierten, unabhängig vom Qualifikator “Ideal”. Also wurde die Zeitbezeichnung entfernt, und die rohe Zahl wurde zur Einheit. Story Points waren ursprünglich Ideal Days mit dem Zeitbezug speziell entfernt, um zu verhindern, dass sie als Zeitverpflichtungen behandelt werden.
Jeffries hat seitdem direkt darüber geschrieben. “Ich sage gerne, dass ich Story Points möglicherweise erfunden habe”, schrieb er 2019, “und wenn ich das getan habe, tut es mir jetzt leid.” Er gehört jetzt zu den prominentesten Befürwortern von #NoEstimates — der Position, dass das Problem nicht ist, welche Schätzeinheit man verwendet, sondern dass Schätzung bei komplexer Arbeit unabhängig von der Einheit grundlegend unzuverlässig ist.
Es lohnt sich zu fragen, warum der Wechsel zu IPDs jetzt passiert. Die Antwort ist nicht, dass Teams eine bessere Schätzmethode gefunden haben. Es ist, dass IPDs mit der Wasserfall-Finanzinfrastruktur übereinstimmen — den Budgetzyklen, Projektbuchhaltungssystemen, Vertragsabrechnungsmodellen und Personalplanungswerkzeugen, die Organisationen rund um zeitbasierte Planung aufgebaut und nie geändert haben, als sie Agile adoptierten. Story Points passen nicht in diese Systeme. IPDs schon.
Das ist keine Evolution von Agile. Es ist Wasserfall, der sich weiterhin in Agiles Kleidung neu behauptet — unter Verwendung der Finanzstrukturen, die nie abgebaut wurden, um die Praxis zurück in Richtung des Modells zu ziehen, für das diese Strukturen gebaut wurden. Die Schätzeinheit hat sich geändert; das Organisationssystem, das zeitbasierte Verpflichtungen fordert, hat es nicht. Das Ergebnis ist das gleiche Prognosetheater, nur mit einem neuen Namen.
Das sind nicht Unternehmen, die endlich die Kontrolle übernehmen und korrigieren, was Agile verfehlte. Es sind Unternehmen, die die Infrastruktur neu behaupten, die sich nie geändert hat. IPDs erfordern keine Verschiebung in Denken, Verständnis oder Gedanken — man beschriftet einfach das um, was man bereits weiß. Genau deshalb gewinnen sie an Boden.
Die Agile-Gemeinschaft hat hier eine Führungschance verpasst. Als die Forderung nach zeitbasierten Prognosen als IPDs verkleidet zurückkehrte, war die richtige Antwort, zu benennen, was passierte: Das ist Wasserfall-Finanzierung, die sich über Agile-Praxis neu behauptet. Stattdessen haben viele Praktiker sie untergebracht und die Forderung als zu verwaltende Einschränkung behandelt anstatt als zu korrigierende Kategorienfehler. Das Ergebnis ist, dass die Teams, die am flüssigsten im Agile-Vokabular sind, oft die ausgefeilteste Version des Modells ausführen, das Agile zu ersetzen konzipiert wurde.
Die Menschheit lernt langsam
Es gibt hier ein Muster, das tiefer als Schätzmethodologie geht. Es ist das Muster, eine Etikettänderung als Praxisänderung zu behandeln — die Adoption neuen Vokabulars mit dem Denkwandel zu verwechseln, den dieses Vokabular vertreten sollte.
Einsteins Definition von Wahnsinn wird oft zitiert, meist falsch zugeschrieben, aber verlässlich resonant: immer wieder dasselbe zu tun und andere Ergebnisse zu erwarten. Die Zuschreibung ist wahrscheinlich apokryph. Das Muster ist es nicht. Organisationen, die Agile-Zeremonien ohne Agile-Denken adoptierten, adoptieren jetzt Agiles Ersatz-Zeremonien, ohne zu untersuchen, ob das zugrundeliegende Denken sich geändert hat. Die Worte sind anders. Das Modell ist dasselbe.
Das Gespräch, das dieser Beitrag zu öffnen versucht, geht nicht um Schätzeinheiten. Es geht darum, ob Ihre Organisation wirklich erwogen hat, was komplexe Arbeit ist und was sie erfordert. Wenn die Antwort ist, dass sich Ihre Planungsinfrastruktur nicht geändert hat — dass Sie immer noch Prognosen, Commitments und zeitbasierte Buchhaltung brauchen, die davon ausgehen, dass vorausschauende Analyse zuverlässige Vorhersagen liefert — dann ist die Schätzdebatte ein Symptom. Die Bedingung, auf die sie hinweist, ist, dass der Wandel, den Agile vorschlug, noch nicht stattgefunden hat.
Kommentare 0