Die Frage, ob ein Softwareprojekt über Meilensteine oder Sprints gesteuert wird, klingt nach einer Methodendebatte für Projektleiter. Sie entscheidet aber darüber, wie belastbar der Projektstatus ist, wie gleichmäßig ein Team arbeiten kann und wie früh eine Fehlplanung sichtbar wird. Für Auftraggeber ist das keine Formfrage, denn beide Modelle liefern eine sehr unterschiedliche Qualität an Information.

Warum Meilensteine künstlichen Druck erzeugen

Klassische Meilensteine wirken in der Praxis häufig willkürlich gesetzt. Entweder sind sie es tatsächlich, weil ein Datum aus einer Vertragsverhandlung oder einer Präsentation stammt, oder sie sind gut begründet, aber schlecht kommuniziert. Für das Team ist der Unterschied zunächst nicht erkennbar.

Die Folge ist eine ungleichmäßige Belastung. Ein Meilenstein ist nur mit erheblichen Zusatzanstrengungen erreichbar, weil zufällig mehrere aufwendige Themen in denselben Zeitraum fallen. Der nächste ist dann fast beiläufig zu schaffen. Vor dem einen Termin arbeitet das Team Überstunden, danach fahren erst einmal alle in Urlaub. Das lässt sich so betreiben, hat aber wenig mit Steuerung zu tun. Es erzeugt Druck, der nicht aus der Sache kommt, sondern aus der Planung.

Der zweite Nachteil betrifft die Information. Zwischen zwei Meilensteinen gibt es lange Phasen, in denen der Fortschritt nur über Berichte sichtbar ist, nicht über fertige Ergebnisse. Ob ein Projekt noch im Rahmen liegt, wird an wenigen Zeitpunkten überprüft, und wenn ein Meilenstein reißt, ist bereits viel Zeit vergangen. Genau dieses Muster steckt hinter der Erfahrung, die in Ein Feature zwei Monate zu spät beschrieben ist.

Was Meilensteine leisten sollen

Der Zweck ist unbestritten: Man braucht Punkte, an denen erkennbar ist, ob ein Projekt auf Kurs liegt. Ohne solche Punkte gibt es keinen Abgleich zwischen Plan und Wirklichkeit, und bei mehrjährigen Vorhaben mit externen Abhängigkeiten sind Termine ohnehin gesetzt.

Das Problem liegt nicht im Prinzip, sondern in der Auflösung. Vier Kontrollpunkte in achtzehn Monaten sind zu wenig, um früh zu reagieren. Wer nur alle Quartale einen belastbaren Abgleich hat, erfährt Abweichungen mit Quartalsverzögerung. Zwischen den Kontrollpunkten bleibt der Status eine Einschätzung, und Einschätzungen fallen tendenziell optimistisch aus. Warum Schätzungen ohnehin systematisch zu niedrig ausfallen, behandelt Softwareprojekte schätzen.

Was Sprints anders machen

Aus dem Umfeld der agilen Methoden ist vor allem ein Element uneingeschränkt empfehlenswert: der feste, kurze Takt. Alle zwei Wochen ein abgeschlossener Zeitraum mit geplantem Inhalt, kein Auf und Ab, keine künstlich gesetzten Termine, gleichmäßige Last. Das Team weiß von Beginn an, welche Inhalte in welchen Takt gehören.

Die Vorteile sind praktisch, nicht ideologisch:

• Konstante Belastung statt Wechsel zwischen Überstunden und Leerlauf. Das ist der Punkt, der sich am unmittelbarsten auf Qualität und Fluktuation auswirkt.
• Ein belastbarer Status alle zwei Wochen. Nach jedem Takt ist sichtbar, was fertig ist und was nicht, und zwar an Ergebnissen, nicht an Prozentangaben.
• Sofortige Nachsteuerung. Die Planung der folgenden Takte lässt sich direkt anpassen. Überschreitet der offene Aufwand die Kapazität bis zum Projektende, wird das unmittelbar sichtbar.
• Eine klare Entscheidungslage. Wenn die Planung nicht mehr aufgeht, gibt es drei Wege: Zeitplan verlängern, Team verstärken oder Umfang reduzieren, so lange, bis eine plausible Planung steht.

Der letzte Punkt ist der eigentliche Gewinn. Er zwingt zu einer Entscheidung, während noch Handlungsspielraum besteht. Bei einem Meilenstein-Modell fällt dieselbe Entscheidung meist erst dann an, wenn nur noch die Wahl zwischen schlechten Optionen bleibt. Voraussetzung ist allerdings, dass Auftraggeber und Dienstleister denselben Blick auf den Status haben. Wie unterschiedlich die Erwartungen dabei ausfallen können, zeigt Erwartungen in IT-Projekten.

Wo echte Termine trotzdem gelten

Ein Takt ersetzt keine externen Fixtermine. Eine gesetzliche Frist, ein Messeauftritt, die Ablösung eines Systems zum Ende eines Wartungsvertrags, der Stichtag einer Datenübernahme: solche Termine sind real, nicht verhandelbar und gehören in jede Planung.

Der Unterschied liegt darin, wie damit umgegangen wird. Ein externer Fixtermin ist eine Randbedingung, an der der Umfang ausgerichtet wird. Ein intern gesetzter Meilenstein ist dagegen häufig nur eine Zwischenkontrolle, die als harter Termin verkauft wird. Wer beides trennt, kann mit wenigen echten Terminen arbeiten und den Rest über den Takt steuern. In der Praxis reduziert sich die Zahl der wirklich unverrückbaren Termine dabei deutlich, oft auf einen oder zwei pro Projekt.

Wichtig ist außerdem, dass ein zweiwöchiger Takt nicht bedeutet, alle zwei Wochen produktiv auszuliefern. Der Takt strukturiert Planung und Abgleich. Wie oft tatsächlich in Produktion gebracht wird, ist eine getrennte Frage, die von Freigabeprozessen, Testaufwand und Risiko abhängt.

Das Problem ist der Name

Bleibt ein Einwand gegen Sprints, und der betrifft die Bezeichnung. Wieso nennt man einen Zeitraum Sprint, den man über Monate durchhalten will? Der Begriff suggeriert Vollgas, und Vollgas über Monate ist nicht realistisch. Was gemeint ist, ist ein gleichmäßiger Dauerlauf mit festem Rhythmus. Diese sprachliche Kleinigkeit hat praktische Folgen, weil sie in Führungsgesprächen falsche Erwartungen erzeugt. Wer den Begriff im eigenen Unternehmen durch etwas Passenderes ersetzt, etwa Takt oder Etappe, nimmt dem Modell nichts von seiner Wirkung.

Fazit

Die Wahl zwischen Meilensteinen oder Sprints ist keine Methodenfrage, sondern eine Frage der Auflösung. Wenige, weit auseinanderliegende Kontrollpunkte erzeugen ungleichmäßige Last und späte Erkenntnisse. Ein fester, kurzer Takt liefert alle zwei Wochen einen belastbaren Status und macht Abweichungen früh sichtbar, solange sie noch steuerbar sind. Externe Fixtermine bleiben davon unberührt, sie sind Randbedingung und nicht Steuerungsinstrument.