Wofür Schätzung da ist

Schätzung erfüllt drei Aufgaben, und Teams, die sie vermischen, sind mit allen dreien frustriert.

Aufgabe 1: Gemeinsames Verständnis. Wenn ein Team ein Ticket gemeinsam schätzt, ist die Zahl ein Nebenprodukt. Das eigentliche Ergebnis ist das Gespräch. Ein Entwickler sagt „das ist eine kleine Änderung — Endpunkt austauschen und Tests aktualisieren." Ein anderer sagt „Moment, dieser Endpunkt liegt hinter einem Feature-Flag, von dem drei andere Services abhängen." Die Lücke zwischen ihren Schätzungen ist die Lücke zwischen ihren mentalen Modellen der Arbeit. Diese Lücke sichtbar zu machen, bevor die Arbeit beginnt, ist mehr wert als die Zahl es je sein wird.

Aufgabe 2: Kapazitätsplanung. Ein Team mit 10 Entwicklern und einem zweiwöchigen Sprint hat eine begrenzte Menge an Arbeit, die es aufnehmen kann. Schätzung — selbst grobe Schätzung — sagt Ihnen, ob Sie 80 % der Kapazität oder 140 % einplanen. Ohne sie ist Sprint-Planung Raterei, und „wir haben uns zu viel vorgenommen" wird zu einem wiederkehrenden Retrospektiven-Thema.

Aufgabe 3: Priorisierung. Ein Feature, das moderaten Wert liefert und geringen Aufwand kostet, ist ein anderes Gespräch als ein Feature, das denselben Wert liefert und großen Aufwand kostet. Schätzung gibt Produkt und Engineering eine gemeinsame Sprache für Abwägungen. Ohne sie wird Priorisierung zu einer Frage, wer am lautesten argumentiert.

Manche Arbeit kann wirklich nicht geschätzt werden, und so zu tun, als ob, produziert Zahlen, die mehr irreführen als informieren.

Ein Ticket, das sagt „untersuchen, warum der Payment-Webhook zeitweise fehlschlägt", ist nicht schätzbar. Der Entwickler weiß nicht, ob die Grundursache eine Race Condition, ein API-Timeout eines Drittanbieters, eine falsch konfigurierte Retry-Policy oder etwas ganz anderes ist. Es als „mittel" zu schätzen, weist nur einer Unwissenheit eine Zahl zu — und jetzt behandelt der Sprint-Plan diese Zahl, als ob sie etwas bedeutet.

Die ehrliche Antwort ist „Ich weiß es nicht, und ich brauche einen Spike, um es herauszufinden." Ein Spike ist eine zeitlich begrenzte Untersuchung — typischerweise einen halben bis zwei Tage — deren Ergebnis kein funktionierender Code ist, sondern Information. Nach dem Spike weiß das Team genug, um den eigentlichen Fix zu schätzen. Spikes sind kein Versagen der Schätzung; sie sind Schätzung, die korrekt funktioniert, indem sie ihre eigenen Grenzen zugibt.

Dasselbe gilt für wirklich neuartige Arbeit: eine neue Integration mit einer unbekannten API, eine Migration zu einer Technologie, die das Team nicht verwendet hat, oder ein Performance-Problem ohne offensichtlichen Engpass. Eine Schätzung für diese Tickets zu erzwingen, produziert keine nützliche Information — sie produziert eine Zahl, die das Team sich verpflichtet fühlt zu erreichen, und einen Plan, der auf Fiktion basiert.

Teams, die von Schätzgenauigkeit besessen sind, optimieren das Falsche. Ein Team, dessen Schätzungen konstant um 30 % daneben liegen, das aber das Schätzgespräch nutzt, um Annahmen sichtbar zu machen, Scope-Lücken zu erkennen und sich auf den Ansatz abzustimmen, erhält mehr Wert aus der Schätzung als ein Team, dessen Zahlen perfekt landen, das aber schweigend schätzt.

Die Zahl ist ein Nebenprodukt. Das Gespräch ist das Produkt. Wenn zwei Entwickler dasselbe Ticket unterschiedlich schätzen, ist diese Uneinigkeit Information — einer von ihnen weiß etwas, das der andere nicht weiß, oder sie stellen sich unterschiedliche Implementierungen vor. Diese Uneinigkeit zu klären, bevor die Arbeit beginnt, verhindert Nacharbeit, fängt fehlende Anforderungen ab und baut gemeinsamen Kontext im Team auf.

Deshalb übertreffen Schätzmethoden, die Gespräch erzwingen (wie Planning Poker, wo alle gleichzeitig aufdecken), Methoden, die das nicht tun (wie eine Person, die eine Zahl nennt und fragt „klingt das richtig?"). Das Aufdecken geht nicht um die Zahl — es geht um die Lücke. Ein Ticket, bei dem alle eine 3 zeigen, ist langweilig. Ein Ticket, bei dem eine Person eine 2 und eine andere eine 8 zeigt, ist dort, wo Schätzung sich bezahlt macht.