Stell dir vor: E-Commerce-Plattform, Migrationsprojekt. Altes Monolith-Backend raus, neue Services rein. Das Team schätzt: zwölf Wochen. Nicht aus dem Bauch raus 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 werden sie zusammengesteckt.
Der OrderService schickt Events an den InventoryService, aber die Serialisierung ist inkompatibel. Der ProductService braucht Daten aus dem OrderService, aber das API-Modell passt nicht zum internen Domain-Modell. Drei Services die einzeln perfekt funktionieren, zusammen aber Wochen an Debugging verschlingen. Am Ende sind es nicht zwölf Wochen. Es sind neunzehn.
Sieben Wochen daneben. Bei drei Services.
Wo die Zeit verschwindet
Stell dir vor, du trackst deine Schätzungen. Sechs Monate lang. Jede Aufgabe, jede Woche: geschätzt vs. tatsächlich. Eine Spalte in Notion, nichts Aufwändiges.
Das Ergebnis ist 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 wird 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.
Wer 40% auf alles addiert wo mehr als ein System beteiligt ist, klingt pessimistisch. Ist aber meistens näher an der Realitä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. Vielleicht ist es Integration. 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
Zurück zum Migrationsprojekt. Stell dir vor: bevor gebaut wird, gibt es ein Requirements-Dokument. 47 Seiten. Jeder Use Case beschrieben, jede Edge Case abgedeckt, jede Stakeholder-Signatur eingeholt. Product Owner, Teamlead, Abteilungsleiter, alle haben unterschrieben. Acht Wochen hat das gedauert.
Zwei Wochen nach Projektstart ist klar: die Hälfte der Requirements ist falsch.
Nicht weil jemand schlecht gearbeitet hat. Sondern weil die Requirements auf dem alten System basieren. Die Leute beschreiben, was sie jetzt tun. Nicht was sie eigentlich brauchen. Ein Requirement: “Bestellungen müssen in der Reihenfolge der Eingabe verarbeitet werden.” Klingt logisch. Wird eingebaut. Kostet zwei Wochen extra weil Ordering-Garantien über drei Services hinweg nicht trivial sind. Nach dem Launch stellt sich heraus: niemand braucht das. Die Sachbearbeiter sortieren die Bestellungen sowieso nach Priorität, 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.” Der Punkt: 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.”
Stell dir vor: ein Team mit 14 Jira-Spalten. Vierzehn. Sprints die bis auf die Stunde durchgeplant sind. Ein Agile Coach der Dailys moderiert, die 45 Minuten dauern. Velocity-Tracking das quartalsweise dem Management präsentiert wird. 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.
Der bessere Ansatz: keine Specs, sondern 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 nicht in einer Zahl schätzen, sondern “zwei bis fünf Wochen, abhängig von der Integration mit Service X.” Das ist unbequemer. Aber unbequem und richtig schlägt bequem und falsch.