Stunden vs. Größen vs. Anzahl

Menschen sind schlecht darin, absolute Zeit zu schätzen, und Entwickler sind da keine Ausnahme. Forschung zum Planungsfehlschluss – der systematischen Tendenz zu unterschätzen, wie lange Aufgaben dauern werden – zeigt durchweg, dass Menschen um einen Faktor von 2 bis 4 unterschätzen, selbst bei Aufgaben, die sie schon einmal gemacht haben. Das Problem ist nicht Faulheit oder Inkompetenz. Das Problem ist kognitiv: Wenn man sich vorstellt, eine Aufgabe zu erledigen, stellt man sich den Happy Path vor. Man stellt sich nicht die instabile Testsuite vor, die unklaren Akzeptanzkriterien, die Abhängigkeit, die letzte Woche aktualisiert wurde, oder die zwei Stunden, die man in Meetings verbringen wird.

Stunden laden auch zu Ankereffekten ein. Sobald jemand sagt „das sind wahrscheinlich etwa 4 Stunden", kreisen alle nachfolgenden Schätzungen um 4. Hätte die erste Person 12 gesagt, wäre die Gruppe auf eine andere Zahl konvergiert – nicht weil sich die Arbeit geändert hat, sondern weil sich der Anker geändert hat. Stunden fühlen sich auf eine Weise präzise an, die zu falschem Vertrauen einlädt. „Das ist eine 6-Stunden-Aufgabe" klingt wie eine Tatsache. Es ist eine Vermutung im Laborkittel.

Die Lösung ist nicht, „besser im Schätzen von Stunden zu werden". Jahrzehntelange Beweise sagen, dass das nicht funktioniert. Die Lösung ist, aufzuhören, eine Maßeinheit zu verwenden, die den Planungsfehlschluss überhaupt erst auslöst, und zu etwas Relativem zu wechseln.

Relative Schätzung umgeht den Planungsfehlschluss, indem sie fragt „wie groß ist das im Vergleich zu etwas, das wir bereits gemacht haben?" statt „wie viele Stunden wird das dauern?" Man sagt nicht die Zukunft voraus – man vergleicht.

Die gängigsten Skalen sind T-Shirt-Größen (S, M, L, XL) und Fibonacci-ähnliche Zahlen (1, 2, 3, 5, 8, 13). Beide funktionieren, weil sie bewusst unpräzise sind. Es gibt keinen bedeutsamen Unterschied zwischen einer 6 und einer 7, also bietet die Skala diese Optionen nicht an. Fibonacci zwingt einen in Kategorien, und die Abstände zwischen den Kategorien wachsen, je größer die Zahlen werden – was der Realität entspricht. Der Unterschied zwischen einer 1 und einer 2 ist bedeutsam. Der Unterschied zwischen einer 13 und einer 15 ist Rauschen.

Der Schlüssel, damit relative Schätzung funktioniert, sind Referenz-Stories. Wählt zwei oder drei abgeschlossene Tickets aus, an die sich das ganze Team erinnert, und weist ihnen Größen zu: „das Redesign der Login-Seite war eine 5, der CSV-Export-Fix war eine 2, die Payment-Integration war eine 13". Jetzt wird jedes neue Ticket mit diesen Referenzen verglichen, nicht mit einer abstrakten Zeitskala. „Ist das eher wie der CSV-Fix oder eher wie das Login-Redesign?" ist eine Frage, die Entwickler mit Zuversicht beantworten können. „Wie viele Stunden wird das dauern?" ist eine Frage, bei der sie falsch liegen werden.

Die einfachste Schätzmethode ist überhaupt keine Schätzung – einfach Tickets zählen. Wenn euer Team etwa 12 Tickets pro Sprint abschließt und das Backlog 15 Tickets für den nächsten Sprint hat, wisst ihr, dass ihr überlastet seid, ohne ein einziges geschätzt zu haben.

Zählen funktioniert, wenn Tickets ungefähr gleich groß sind, was bedeutet, dass es funktioniert, wenn Teams diszipliniert beim Slicing sind. Ein Ticket, das sagt „baue das gesamte Benachrichtigungssystem" und ein Ticket, das sagt „füge eine Null-Prüfung zum Export-Endpoint hinzu" sind keine vergleichbaren Einheiten. Aber ein Team, das durchweg Tickets schreibt, die einen halben bis zwei Tage Arbeit umfassen – wo das größte Ticket höchstens 3–4 Mal so groß ist wie das kleinste – kann die Ticket-Anzahl als zuverlässigen Proxy für Kapazität verwenden.

Die Disziplin, die das erfordert, ist Story Slicing: Arbeit in Stücke zu zerlegen, die klein genug sind, dass die Größenvariation gering ist. Das ist nicht umsonst. Aber es hat einen Nebeneffekt, der möglicherweise wertvoller ist als die Schätzung selbst – kleine, gut definierte Tickets sind einfacher zu reviewen, einfacher zu testen und bleiben seltener eine Woche lang „in Bearbeitung". Die Schätzmethode belohnt genau das Verhalten, das man vom Team ohnehin will.