Es gibt einen hartnäckigen Mythos, dass Scrum Story Points erfordert, oder dass Schätzung ein zentraler, nicht verhandelbarer Pfeiler des Frameworks ist. Beides stimmt nicht, und die Verwirrung lohnt sich zu klären, weil sie prägt, wie Teams über eine genuin optionale Praxis denken.
Was der Scrum Guide tatsächlich sagt
Der Scrum Guide schreibt in seiner aktuellen Form keine bestimmte Schätztechnik vor. Er verlangt keine Story Points, kein Planning Poker, und verlangt nicht einmal, dass Product-Backlog-Elemente überhaupt in formal-numerischem Sinn geschätzt werden. Was er verlangt, ist, dass das Entwicklungsteam genug gemeinsames Verständnis der Arbeit hat, um eine vernünftige Prognose zu treffen, was in einem Sprint geliefert werden kann. Wie dieses Verständnis aufgebaut wird, überlässt er dem Team.
Das ist wichtig, weil viel von dem, was Teams als "Scrum verlangt das" behandeln, tatsächlich "eine verbreitete Umsetzung von Scrum macht das" ist. Story Points, Velocity-Tracking und Fibonacci-Schätzskalen sind weitverbreitete Praktiken, die aus der breiteren Agile-Community entstanden sind, nicht Anforderungen, die im Framework selbst verankert sind.
Warum es Schätzung überhaupt gibt
Schätzung erfüllt einen genuin nützlichen Zweck, wenn sie für Planungsgespräche genutzt wird statt als Leistungskennzahl: Sie erzwingt die Art von Diskussion, die versteckte Komplexität vor Beginn der Arbeit ans Licht bringt, statt mitten im Sprint. Ein Team, das uneins ist, ob eine Story eine 3 oder eine 8 ist, ist oft eigentlich uneins darüber, was die Story tatsächlich erfordert, und die Schätzübung ist es, die diese Uneinigkeit früh genug aufdeckt, um sie günstig zu lösen.
Das Problem entsteht, wenn Schätzungen aufhören, ein Planungswerkzeug zu sein, und stattdessen als Verpflichtung oder Leistungsmaßstab behandelt werden. Sobald Velocity zu einer Zahl wird, die das Management verfolgt und über Sprints oder Teams hinweg vergleicht, verschiebt sich der Anreiz von "genau schätzen, um gut zu planen" zu "so schätzen, dass die Zahl gut aussieht", und die gesamte Praxis erfüllt still ihren ursprünglichen Zweck nicht mehr.
Relative versus absolute Schätzung
Wo Teams schätzen, hält sich relative Schätzung, Arbeit im Verhältnis zu anderer Arbeit zu bemessen statt in absoluten Zeiteinheiten, besser als absolute Schätzung in Stunden oder Tagen. Menschen sind nachweislich schlecht darin, absolute Dauer für unvertraute Arbeit zu schätzen, aber vergleichsweise gut in relativen Urteilen ("das ist ungefähr doppelt so komplex wie das andere Ding, das wir gemacht haben"). Das ist das eigentliche Argument für Story Points gegenüber stundenbasierten Schätzungen, und es ist ein echtes. Es ist nur keine Scrum-Anforderung, sondern eine Reaktion auf eine gut dokumentierte kognitive Grenze.
Die Alternative, zu der manche Teams wechseln
Eine wachsende Zahl von Teams verzichtet ganz auf Schätzung zugunsten dessen, Arbeit klein genug herunterzubrechen, dass die meisten Elemente ähnlich groß sind, und stattdessen Durchsatz zu verfolgen (wie viele Elemente pro Sprint abgeschlossen werden) statt Story Points. Das tauscht das vorgelagerte Schätzgespräch gegen eine Disziplin konsequenter Backlog-Zerlegung, und für Teams, die diese Zerlegung gut beherrschen, entfällt eine ganze Kategorie an Diskussion, ohne den Planungswert zu verlieren, den Schätzung eigentlich liefern sollte.
Keiner der beiden Ansätze ist "korrekteres" Scrum als der andere. Das Framework schweigt zu dieser Frage bewusst und überlässt die Wahl dem Ansatz, der dem tatsächlichen Planungs- und Prognosebedarf eines Teams am besten dient.