Critical Chain: Projektplanung ohne den Schätzungs-Stress

Schätzungen in der Softwareentwicklung sind eine ständige Quelle von Frust. Sie dienen selten der realen Planung. Meistens erzeugen sie lediglich Druck auf die Entwickler, ohne die Zuverlässigkeit der Termine zu erhöhen. Am Ende steht oft die Erkenntnis, dass Software fertig ist, wenn sie fertig ist.

Die Ursache ist das Parkinsonsche Gesetz. Arbeit dehnt sich immer so weit aus, wie Zeit zur Verfügung steht. Geben wir jemandem vier Tage für eine Aufgabe, die in zwei Tagen machbar wäre, wird sie vier Tage dauern. Das liegt nicht an Faulheit, sondern an der menschlichen Natur. Wir polieren Dinge, die nicht poliert werden müssen.

Die drei Saboteure unserer Zeitpläne

Wir können bei fast jedem Projekt drei Faktoren beobachten, die eine realistische Planung von Anfang an verhindern.

Erstens bestimmt oft der Vertrieb oder die Architektur die Liefertermine. Dies geschieht zu einem Zeitpunkt, an dem das eigentliche Entwicklungsteam noch gar nicht feststeht. Die Vorgaben sind also reine Theorie.

Zweitens erleben wir im Team oft eine Form von Selbstsabotage. Einzelne Entwickler schätzen Aufgaben extrem kurz, um kompetent zu wirken. Sie vernachlässigen dabei Tests, Codequalität und notwendige Refactorings. Wenn diese Personen dann in die Vibe-Coding-Falle tappen, entstehen Verzögerungen für das gesamte Team.

Drittens steht uns das eigene Entwickler-Ego im Weg. Wir glauben, dass wir jedes technische Problem in wenigen Stunden lösen können. Das ist menschlich, ignoriert aber die unvorhersehbare Komplexität von Software.

Das Prinzip der Critical Chain

Die Critical Chain Methode bietet einen Ausweg aus diesem Dilemma. Die Kernidee ist fast schon provokant einfach. Wir nehmen die historischen Medianzeiten unserer Aufgaben, halbieren diese und nennen sie aggressive Ziele.

Die entfernte Zeit verschwindet nicht. Sie wandert in einen gemeinsamen Projektpuffer. Dieser Puffer gehört dem gesamten Team.

Braucht ein Entwickler zwei Tage für eine Aufgabe, die nur auf einen Tag geschätzt war, ist das kein Problem. Er entnimmt einfach einen Tag aus dem Projektpuffer. Es gibt keine Bestrafung für das Überschreiten der Vorgabe. Weder formal noch informell. Niemand macht vorwurfsvolle Bemerkungen im Standup.

Das Überschreiten ist eingeplant. Nur durch diese psychologische Sicherheit trauen sich Entwickler, Aufgaben auch wirklich früher abzuschließen. Die gesparte Zeit füllt den Puffer, anstatt in endlosen Refactorings zu verpuffen.

Story Points und historische Mediane

Viele Teams schätzen in Story Points statt in Tagen. Das Prinzip funktioniert trotzdem. Wir exportieren die erledigten Aufgaben des letzten Quartals aus dem Ticketsystem. Dann berechnen wir den Median der Bearbeitungszeit für jeden Story Point Wert.

Der Median ist wichtig, da er Ausreißer ignoriert. Eine Aufgabe, die wegen Urlaub 14 Tage dauerte, verfälscht so nicht das Ergebnis.

Nachdem wir diese Mediane ermittelt haben, kürzen wir sie um die Hälfte. Das ergibt unsere aggressiven Zielvorgaben. Diese Berechnung macht das Management. Die Entwickler arbeiten einfach ganz normal weiter.

Ein echtes Fallbeispiel aus der Praxis

Schauen wir uns an, wie das in der Realität abläuft. Ein Projekt mit 17 Aufgaben, geschätzt auf 70 Story Points. Ein Team aus drei Entwicklern. Der Puffer nach der Halbierung beträgt 35 Story Points.

Wir verfolgen jede Woche nur zwei Kennzahlen. Den Pufferverbrauch und den Projektfortschritt. Der Pufferverbrauch misst, wie viel Zeit über die aggressiven Schätzungen hinaus verbraucht wurde. Der Projektfortschritt misst die erledigten Story Points im Verhältnis zum Gesamtumfang.

Woche eins: Der rote Alarm

In der ersten Woche lag der Pufferverbrauch bei 26 Prozent. Der Fortschritt lag aber nur bei 16 Prozent. Nach klassischen Maßstäben sah die Woche völlig normal aus. Die Metriken auf dem Burndown Chart waren unauffällig. Die Critical Chain Kennzahlen zeigten jedoch ein Problem. Der Puffer brannte schneller ab, als Arbeit fertig wurde.

Eine kurze Retrospektive deckte auf, dass wichtige Anforderungen unklar waren. Die Entwickler verbrachten ihre Zeit mit dem Klären von Fragen statt mit dem Schreiben von Code. Das Problem konnte direkt behoben werden. Ohne Critical Chain wäre dieser Zeitfresser erst viel später aufgefallen.

Woche zwei und drei: Die Wende

In der zweiten Woche schrumpfte die Lücke. Der Pufferverbrauch stieg auf 46 Prozent, der Fortschritt auf 41 Prozent. Die Klärung der Anforderungen aus der Vorwoche zahlte sich aus. Das Management musste hier nur beobachten und nicht eingreifen.

In der dritten Woche überholte der Fortschritt erstmals den Pufferverbrauch. Der Fortschritt lag bei 70 Prozent, der Pufferverbrauch nur bei 63 Prozent. Einige Aufgaben dauerten länger als die aggressive Schätzung. Das war in Ordnung, weil andere Aufgaben deutlich schneller fertig wurden und den Gesamtschnitt retteten.

Woche vier: Projektabschluss

Das Team beendete das Projekt. Es verbrauchte 83 Prozent des Puffers und lieferte 100 Prozent des Umfangs. Die eingesparten 17 Prozent waren reine Zeitersparnis. Der frühe Alarm in der ersten Woche hat vermutlich eine ganze Woche Verzögerung verhindert.

Automatisierung im Alltag

Der Erfolg dieser Methode liegt in der unsichtbaren Integration. Das Team muss keine zusätzlichen Listen pflegen. Wir können das Ticketsystem die Arbeit machen lassen.

Sobald ein Ticket auf Bearbeitung wechselt, setzt das System automatisch ein Fälligkeitsdatum. Dieses Datum basiert auf der gekürzten Medianzeit für den jeweiligen Story Point Wert.

Der Entwickler sieht dieses Datum sofort. Es baut keinen Druck auf, sondern dient als sportliche Herausforderung. Die Auswertung des Puffers läuft vollautomatisch über eine verknüpfte Tabelle im Hintergrund.

Wann die Methode nicht funktioniert

Es gibt Situationen, in denen dieses System scheitert. Bei Teams mit vielen Junior Entwicklern entsteht oft Panik. Sie nehmen die aggressiven Schätzungen persönlich und fürchten Konsequenzen, selbst wenn das Gegenteil kommuniziert wird.

Auch bei extrem erschöpften Teams ist Vorsicht geboten. Wer ohnehin schon an der Belastungsgrenze arbeitet, braucht keine sportlichen Herausforderungen, sondern Entlastung.

Fazit

Die Critical Chain Methode ist ein mächtiges Werkzeug, um Projekte berechenbarer zu machen. Das Team gewinnt Sicherheit. Wer langsam coden, schneller lernen will, braucht genau diesen Freiraum, um saubere Lösungen zu entwickeln und die Architektur im Auge zu behalten. Wir hören auf, künstliche Deadlines zu jagen, und fangen an, echte Puffer als Teamressource zu nutzen.