Letztes Jahr, E-Commerce-Plattform, Migrationsprojekt. Altes Monolith-Backend raus, neue Services rein. Mein Team hat geschätzt: zwölf Wochen. Nicht aus dem Bauch raus, wir haben die Services aufgelistet, Story Points vergeben, Buffer eingeplant. Professionell. Die einzelnen Services? Ziemlich genau. OrderService: drei Wochen geschätzt, 3,5 Wochen gebraucht. ProductService: zwei Wochen geschätzt, zwei Wochen gebraucht. InventoryService: eine Woche geschätzt, eine Woche gebraucht.
Und dann haben wir sie zusammengesteckt.
Der OrderService hat Events an den InventoryService geschickt, aber die Serialisierung war inkompatibel. Der ProductService brauchte Daten aus dem OrderService, aber das API-Modell passte nicht zum internen Domain-Modell. Drei Services die einzeln perfekt funktionierten, zusammen aber Wochen an Debugging verschlungen haben. Am Ende waren es nicht zwölf Wochen. Es waren neunzehn.
Sieben Wochen daneben. Bei drei Services.
Wo die Zeit verschwindet
Ich hab angefangen meine Schätzungen zu tracken. Nicht als Experiment, sondern weil ich es leid war, immer dieselbe Konversation zu führen. “Warum hat das länger gedauert?” — “Ja, weil… unvorhergesehen…” Ich wollte wissen wo. Konkret.
Sechs Monate lang. Jede Aufgabe, jede Woche: geschätzt vs. tatsächlich. Eine Spalte in Notion, nichts Aufwändiges.
Das Ergebnis war brutal eindeutig. Logik innerhalb eines Service: fast immer richtig geschätzt. Plusminus zehn Prozent. Aber Integration: zwei Services verbinden, Datenformate abstimmen, Edge Cases an den Grenzen finden — das hab ich jedes Mal um den Faktor 1,5 bis 2,5 unterschätzt. Jedes. Mal.
Hunt und Thomas schreiben “the first part of any estimation exercise is building an understanding of what’s being asked.” Stimmt. Aber sie meinen damit nicht nur die Aufgabe verstehen. Sie meinen: versteh was du nicht siehst. Die Integration ist das, was du nicht siehst, weil du bei der Schätzung an die einzelnen Teile denkst. Nicht an den Klebstoff dazwischen.
Seitdem addiere ich 40% auf alles wo mehr als ein System beteiligt ist. Mein Manager findet das pessimistisch. Aber in sechs Monaten war ich kein einziges Mal zu spät.
Track deine Schätzungen zwei Sprints lang. Geschätzt vs. tatsächlich, eine Tabelle. Du wirst ein Muster sehen. Nicht dass du generell schlecht schätzt, sondern dass du an einer bestimmten Stelle blind bist. Bei mir ist es Integration. Bei dir ist es vielleicht Testing, Deployment, oder “Abstimmung mit dem anderen Team.” Du weißt es erst wenn du hinschaust.
Hunt und Thomas empfehlen Schätzungen in passenden Einheiten: unter einer Woche in Tagen, bis sechs Wochen in Wochen. Darüber? Sag “ich weiß es nicht” und brich das Projekt kleiner. Eine Schätzung von “drei Monaten” ist keine Schätzung. Das ist Hoffnung mit Kalender.
Requirements sind Wetten
Dasselbe Migrationsprojekt. Bevor wir angefangen haben zu bauen, gab es ein Requirements-Dokument. 47 Seiten. Jeder Use Case beschrieben, jede Edge Case abgedeckt, jede Stakeholder-Signatur eingeholt. Product Owner, Teamlead, Abteilungsleiter, alle hatten unterschrieben. Acht Wochen hat das gedauert.
Zwei Wochen nach Projektstart war klar: die Hälfte der Requirements war falsch.
Nicht weil jemand schlecht gearbeitet hat. Sondern weil die Requirements auf dem alten System basierten. Die Leute beschrieben, was sie jetzt tun. Nicht was sie eigentlich brauchen. Ein Requirement war: “Bestellungen müssen in der Reihenfolge der Eingabe verarbeitet werden.” Klingt logisch. Haben wir eingebaut. Hat zwei Wochen extra gekostet weil Ordering-Garantien über drei Services hinweg nicht trivial sind. Nach dem Launch hat sich herausgestellt: niemand hat das je gebraucht. Die Sachbearbeiter haben die Bestellungen sowieso nach Priorität sortiert, nicht nach Eingang.
Zwei Wochen Arbeit für ein Requirement das aus der Gewohnheit einer einzigen Person kam.
Das Buch nennt das den Requirements Pit — “requirements rarely exist on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics.” Was ich daraus gezogen hab: Requirements sind keine Fakten. Sie sind Wetten. Jemand wettet, dass Nutzer Feature X brauchen. Manchmal gewinnt die Wette. Manchmal verbrennst du zwei Wochen für ein Ordering-Guarantee das nie jemand bemerkt hätte.
Und ja, ich höre den Einwand: “Aber manchmal brauchst du ein detailliertes Spec.” Stimmt. Wenn du eine Schnittstelle zu einem Zahlungsanbieter baust, willst du jedes Feld dokumentiert haben. Wenn du regulatorische Anforderungen umsetzt, willst du Schwarz auf Weiß sehen was geprüft wird. Die “Requirements sind Hypothesen”-Idee funktioniert für Product Features. Für Compliance nicht. Der Unterschied: bei Compliance weiß jemand was richtig ist. Bei Features rät jeder.
”Wir machen Agile”
Eine Sache noch, weil das Buch es anspricht und weil es mich seit Jahren nervt.
“Agile is not a noun; agile is how you do things.”
Ich war in einem Team mit 14 Jira-Spalten. Vierzehn. Sprints die bis auf die Stunde durchgeplant waren. Ein Agile Coach der Dailys moderiert hat, die 45 Minuten dauerten. Velocity-Tracking das quartalsweise dem Management präsentiert wurde. Und am Ende jedes Sprints die Frage: “Warum haben wir unsere Velocity nicht erreicht?”
Weil ihr keinen agilen Prozess habt. Ihr habt Wasserfall mit Post-Its.
Agil heißt: dein Team merkt am Dienstag dass die Annahme falsch war. Am Mittwoch redet ihr mit dem Stakeholder. Am Donnerstag baut ihr in die andere Richtung. Das geht mit Scrum, ohne Scrum, mit Kanban, auf einem Zettel an der Wand. Ob du Jira oder ein Whiteboard benutzt ist so relevant wie die Farbe deines Editors.
Das Buch unterscheidet zwischen Requirements und Policies. “Nur autorisierte Nutzer dürfen Transaktionen sehen” ist ein Requirement. “Nutzer müssen sich mit Username und Passwort einloggen” ist eine Policy, eine mögliche Implementierung. Die meisten Requirements-Dokumente bestehen zu 70% aus Policies.
Was sich konkret geändert hat: ich schreibe keine Specs mehr. Ich schreibe Hypothesen. “Wir glauben, dass X das Problem Y löst. Wir messen das an Z.” Hypothesen laden ein, widerlegt zu werden. Specs laden ein, befolgt zu werden, auch wenn sie falsch sind. Und ich schätze nicht mehr in einer Zahl. Ich sage “zwei bis fünf Wochen, abhängig von der Integration mit Service X.” Das ist unbequemer. Aber unbequem und ehrlich schlägt bequem und falsch.