Schätzungen sind ein Vertrauensproblem — wenn Maschinen schätzen

Es war ein Dienstag im Frühjahr 2009, irgendwo in München. Der Moderator schrieb eine User Story an die Wand: „Als Kunde möchte ich ein Passwort zurücksetzen können." Fünf Entwickler schauten sich an. Der eine hielt 5 Finger hoch. Die andere 8. Jemand sagte 3.

Was dann passierte, dauerte zehn Minuten und sah von außen aus wie Zeitverschwendung. Das Team debattierte. Muss der E-Mail-Service extra konfiguriert werden? Braucht es Datenbankmigrationen? Einer fragte, ob die bestehende Infrastruktur das überhaupt hergibt. Am Ende einigten sich alle auf 5 — ein paar Skeptiker nickten ungern, aber sie nickten.

Das war kein Messprozess. Das war ein Vertrauensritual.

Niemand im Raum konnte die Zukunft vorhersagen. Aber gemeinsam sagten sie etwas anderes als eine Zahl. Sie sagten: Wir verstehen diese Aufgabe. Wir kennen unseren Code. Wir trauen uns das in diesem Sprint zu. Die Schätzung war nie die Antwort auf eine technische Frage — sie war die Antwort auf eine menschliche: Können wir uns selbst vertrauen?

Was Story Points nie waren

2010 habe ich auf meinem Blog geschrieben: „Story Points are not a new measuring unit for input of work. Different inputs of work are not relative to each other. Only amounts of functionality can be relative to each other." Ich wollte damit etwas Einfaches sagen, das erstaunlich schwer zu begreifen war: Story Points messen nicht, wie lange etwas dauert. Sie messen, wie gut ein Team eine Aufgabe verstanden hat.

Ein Team, das sich nicht verständigt, schätzt chaotisch — jeder hat ein anderes Bild im Kopf, und die Zahlen springen wild. Ein Team, das miteinander spricht, schätzt kohärent. Nicht weil es die Zukunft kennt, sondern weil es sich auf ein gemeinsames Verständnis geeinigt hat. Wenn ein Team „13 Points" sagt, heißt das nicht „13 Tage". Es heißt: Da steckt mehr Unbekanntes drin als in einer 5er-Story, und wir wissen das.

Die Industrie hat das nie verstanden. Oder sie wollte es nicht verstehen, weil die Alternative — vertrauen, statt zu kontrollieren — zu unbequem war. Manager nahmen die Velocity und rechneten rückwärts. Wenn das Team 40 Punkte pro Sprint schafft und das Backlog 200 Punkte hat, sind wir in fünf Sprints fertig. Und wenn wir in vier Sprints fertig sein müssen, dann muss die Velocity auf 50 steigen.

So wurde aus einem Verständnisritual ein Machtkampf.

Commitment oder Forecast — der Bruch

2008 habe ich in meinem Sprint-Planning-Post beschrieben, wie das eigentlich gedacht war: „The Team decides what they can do, they tell all the others what they want to do. The reason for this is: We do want to get rid of any attempt to push the team to deliver more than they think they can."

Das Team sagt. Nicht das Management. Das Team.

Dann kam der Scrum Guide 2011 und ersetzte ein einziges Wort. Aus „Commitment" wurde „Forecast". Ich habe damals dagegen angeschrieben: „Commitment bedeutet, dass ich mein Bestes gebe und mit all meiner Kraft daran arbeite, gemeinsam mit den anderen ein Ziel zu erreichen. Commitment bedeutet nicht, an den Pranger gestellt zu werden, wenn es doch nicht gelingt. Commitment ist Ausdruck des Wollens und der Freiwilligkeit — es ist die Basis von Scrum."

Der Unterschied klingt akademisch. Er ist es nicht. Forecast klingt wie Wissenschaft, wie Vorhersage, wie etwas das man überprüfen und korrigieren kann. Commitment klingt wie Versprechen, wie Mut, wie etwas das man aus Überzeugung eingeht. Ein Team, das ein Commitment abgibt, trägt es selbst. Ein Team, das einen Forecast macht, liefert eine Zahl ab und wartet auf die Reaktion von oben.

Mit diesem einen Wort verschwand etwas Wesentliches aus Scrum. Die Freiwilligkeit.

Stolz oder Depression

2015 habe ich den Mechanismus beschrieben, der daraus folgt. Ein Team, das undercommitted — also weniger verspricht, als es vermutlich schafft — kommt mit stolzgeschwellter Brust vom Review. Es hat geliefert und noch etwas draufgelegt. Das ist positive Motivation, und sie wirkt stärker als jede Zielvereinbarung.

Ein Team, das overcommitted, schafft 17 von 21 Points. Die Zahlen sind rot. Und obwohl diese Menschen hart gearbeitet haben, geht die Stimmung in den Keller. Das ist stille Depression. Nicht weil sie weniger geleistet hätten — sondern weil die Erwartung höher war als das Ergebnis.

Diese Unterscheidung war nie ein mathematisches Problem. Sie war immer ein Problem der Psychologie, der Freiwilligkeit und des Vertrauens. Wer darf die Grenze setzen? Das Team — oder die Tabelle?

Die Maschine schätzt jetzt

GitHub Copilot schätzt Story Points. Claude kann das. GPT-4 kann das. Startups trainieren Modelle auf Code-Repositories und liefern erstaunlich zuverlässige Zahlen. Die Velocity-Kurven werden sauberer, die Prognosen genauer, die Überraschungen seltener.

Und das Vertrauensritual ist weg.

Die KI sitzt nicht im Meeting. Sie kennt nicht die stille Debatte, die Fragen, die keiner laut stellt, die Unsicherheit im Blick der Junior-Entwicklerin, die nicht zugeben will, dass sie die Story nicht versteht. Die KI sieht ein Jira-Ticket, vergleicht es mit historischen Daten und sagt: „Das ist eine 5."

Bei der Magic Estimation — einem Verfahren, das wir seit Jahren nutzen — schätzt das Team in Stille. Kein Druck, kein Social Engineering. Und wenn jemand eine Story nicht versteht, wird sie sofort auf die höchste Stufe gesetzt. Nicht verstanden bedeutet: zu riskant. Das ist eine zutiefst menschliche Logik. Unwissen wird nicht bestraft, sondern ernst genommen.

Eine Maschine kennt kein Unwissen. Sie kennt nur Wahrscheinlichkeiten.

Die eigentliche Frage

Hannah Arendt unterschied Arbeiten, Herstellen und Handeln. Nur Handeln ist frei — und nur Handeln trägt Verantwortung, weil sein Ausgang nicht feststeht. Ein Team, das gemeinsam schätzt, handelt. Es setzt sich einer offenen Zukunft aus und sagt trotzdem: Das trauen wir uns zu. Eine Maschine, die schätzt, berechnet. Sie hat keine Verantwortung, keine Angst und kein Vertrauen.

Wenn die Schätzung falsch ist — wer trägt dann die Konsequenzen? Der Manager, der auf die Maschine vertraut hat? Das Team, das übergangen wurde? Oder niemand, weil es ja „nur ein Algorithmus" war?

Ich sehe Teams, die sagen: „Endlich müssen wir nicht mehr stundenlang schätzen." Und ich verstehe die Erleichterung. Aber die Meetings waren nie das Problem. Die Meetings waren der Punkt — der Ort, an dem ein Team seine eigene Kompetenz spürte und lernte, miteinander zu verhandeln.

2010 habe ich geschrieben: „You can't know what you don't know. This kind of integrity creates a trusting relationship." Integrität entsteht, wenn Menschen ehrlich sagen, was sie nicht wissen. Das ist unbequem. Das ist langsam. Und es ist durch nichts zu ersetzen.

Die Maschine liefert bessere Zahlen. Das stimmt wahrscheinlich. Aber die Frage war nie, wie genau die Zahlen sind. Die Frage war immer, wie viel Vertrauen wir in die Menschen investieren, die mit dem Code leben müssen — und ob wir bereit sind, ihnen zuzuhören, wenn sie sagen: Das schaffen wir. Oder: Das schaffen wir nicht.

Das ist kein technisches Problem. Das war es nie.