In agilen Projekten funktionieren Meilensteine, wenn sie an Releases, externe Termine und Entscheidungspunkte geknüpft werden statt an Feature-Umfang. Sprint-Enden sind keine Meilensteine — sie sind Teamzyklen ohne Entscheidungscharakter und gehören nicht in den Plan für den Auftraggeber.
Woher der Konflikt kommt
Klassische Meilensteine setzen voraus, dass der Umfang zu Beginn bekannt ist: Man weiss, was geliefert wird, und plant, wann es fertig ist. Agile Vorgehen kehren das um — der Termin steht, der Umfang ist die verhandelbare Grösse. Ein Meilenstein «alle Funktionen umgesetzt» ist in diesem Modell definitionsgemäss nicht planbar.
Die übliche Reaktion ist einer von zwei Fehlern. Entweder verzichtet das Team ganz auf Meilensteine und lässt die Umgebung ohne Orientierung zurück — was Vertrauen kostet und Eskalationen provoziert. Oder es werden klassische Meilensteine über eine agile Umsetzung gelegt, was die Iterationslogik aushebelt, weil der Umfang faktisch doch fixiert ist.
Was in agilen Projekten als Meilenstein taugt
| Taugt als Meilenstein | Taugt nicht | Warum |
|---|---|---|
| Release in Produktion | Sprint-Ende | Der Sprint ist ein Teamzyklus ohne externe Entscheidung |
| Externer Stichtag (Gesetz, Vertrag) | Story-Punkte erreicht | Punkte sind Teammetrik, kein Zustand |
| Entscheid über Fortsetzung | «Backlog abgearbeitet» | Ein Backlog ist per Definition nie fertig |
| Erste produktive Nutzung | «Alle Features fertig» | Fixiert den Umfang und hebt Agilität auf |
| Abnahme eines Increments | «80 % umgesetzt» | Nicht binär prüfbar |
Das Muster in der linken Spalte: Alle diese Meilensteine beziehen sich auf einen Zustand ausserhalb des Teams — etwas ist in Betrieb, jemand hat entschieden, ein Datum ist erreicht. Die rechte Spalte enthält Teaminterna, die als Steuerungsgrösse für den Auftraggeber ungeeignet sind.
Sprint-Enden sind keine Meilensteine
Der häufigste Fehler in gemischten Umgebungen: Jedes Sprint-Ende wird als Meilenstein in den Projektplan übernommen. Bei zweiwöchigen Sprints über ein Jahr ergibt das sechsundzwanzig Meilensteine — und damit keinen einzigen, der Gewicht hat.
Ein Sprint-Ende ist ein Überprüfungspunkt des Teams: Das Increment wird gezeigt, das Feedback fliesst ins Backlog, die nächste Iteration beginnt. Es fällt keine Entscheidung über die Fortsetzung des Projekts. Genau dieses Merkmal fehlt, und deshalb ist es kein Meilenstein im Sinne der Projektsteuerung.
Sprints gehören in die Teamplanung. Meilensteine gehören in den Plan, den der Auftraggeber sieht. Wer beides in ein Dokument mischt, macht die wenigen echten Entscheidungspunkte unsichtbar.
Umfang statt Termin verhandeln
Der produktivste Umgang mit Meilensteinen in agilen Projekten besteht darin, den Termin festzuhalten und den Umfang explizit zur Verhandlungsmasse zu erklären. Der Meilenstein lautet dann nicht «Funktionen A bis Z in Produktion», sondern «Release 1 in Produktion, Mindestumfang: A, B, C».
Diese Formulierung ist ehrlicher als beide Alternativen. Sie gibt der Organisation den Termin, den sie braucht, und dem Team den Spielraum, den es braucht. Der Mindestumfang ist dabei der harte Teil — er muss klein genug sein, um sicher erreichbar zu sein, sonst ist nichts gewonnen.
Hybride Konstellationen
In der Praxis liegt die häufigste Konstellation in der Mitte: Ein Projekt hat klassische Phasen mit Freigaben und darin eine agil umgesetzte Realisierung. Die Meilensteine liegen dann an den Phasengrenzen, während innerhalb der Realisierung in Sprints gearbeitet wird.
Das funktioniert, wenn zwei Bedingungen erfüllt sind. Erstens muss die Realisierungsphase eigene Zwischenmeilensteine haben — sonst entsteht ein monatelanger Abschnitt ohne Entscheidungspunkt. Zweitens dürfen diese Zwischenmeilensteine nicht an Feature-Listen hängen, sondern an lieferbaren Increments. Sonst ist die Agilität nur ein Vokabular über einem Wasserfall.
Was das Reporting betrifft
Gegenüber dem Auftraggeber berichten agile Projekte am besten zweigleisig: Meilensteine für die Termine und Entscheidungen, Durchsatzmasse für die Aussage, ob das Tempo trägt. Velocity oder Zykluszeit beantworten die Frage, die ein Meilensteinplan in agilen Projekten offenlässt — nämlich ob der nächste Termin realistisch ist.
Häufige Fragen
- Gibt es Meilensteine in agilen Projekten?
- Ja, aber sie werden anders angesetzt: an Releases, externe Stichtage und Entscheidungspunkte statt an Feature-Umfang. Ein Meilenstein wie «alle Funktionen umgesetzt» ist in agilen Vorgehen definitionsgemäss nicht planbar, weil der Umfang die verhandelbare Grösse ist.
- Sind Sprint-Enden Meilensteine?
- Nein. Ein Sprint-Ende ist ein Überprüfungspunkt des Teams, an dem keine Entscheidung über die Fortsetzung des Projekts fällt. Sprint-Enden in den Projektplan zu übernehmen erzeugt bei zweiwöchigen Sprints Dutzende Einträge ohne Steuerungswert.
- Wie formuliert man Meilensteine, ohne Agilität aufzugeben?
- Termin festhalten, Umfang als Verhandlungsmasse ausweisen: «Release 1 in Produktion, Mindestumfang A, B, C». Der Mindestumfang muss klein genug sein, um sicher erreichbar zu sein — sonst ist der Spielraum nur nominell.