Kostenlose Rechner

Release-Prognose: Wann ist der Backlog fertig?

Für: Product Owner und Projektleiter, die einen Release-Termin zusagen oder verteidigen müssen.

Kurz erklärt

Release-Prognose = verbleibende Story Points ÷ Velocity = Anzahl Sprints, mal Sprintlänge = Wochen. Weil die Velocity schwankt (typisch ±20 %), ist das Ergebnis eine Spanne: 200 Punkte bei 40 ± 8 pro Sprint sind 4.2 bis 6.3 Sprints — nicht «fünf».

Eingaben

Verbleibender Backlog (Punkte)Velocity pro Sprint (Punkte)Schwankung der Velocity (%)Aus den letzten Sprints: (max − min) ÷ 2 ÷ Durchschnitt. 20 % ist ein typischer Wert.Sprintlänge (Wochen)

Ergebnis

Erwartet

Wochen bis zum Release

Sprints erwartet: 5
Optimistisch (Wochen): 8.3
Pessimistisch (Wochen): 12.5

Rechenweg: Sprints = Backlog ÷ Velocity. Optimistisch mit Velocity × (1 + Schwankung), pessimistisch mit Velocity × (1 − Schwankung). Wochen = Sprints × Sprintlänge.

Neue Anforderungen während der Arbeit (Scope-Wachstum) sind nicht enthalten — erfahrungsgemäss 10–30 % des Backlogs. Wer das kennt, erhöht den Backlog entsprechend.

Rechnet im Browser. Nichts wird gespeichert oder übertragen.

«Wann ist es fertig?» ist bei agiler Arbeit die schwierigste Frage — nicht, weil niemand rechnen kann, sondern weil die Antwort eine Spanne ist und die Frage ein Datum will. Dieser Rechner liefert die Spanne, ehrlich, und die Argumente, sie zu erklären.

Die Spanne ist die Antwort

Ein einzelnes Datum ist ein Versprechen, das mit 50 % Wahrscheinlichkeit bricht. Eine Spanne mit Begründung ist eine Aussage, die hält. Für Stakeholder: den pessimistischen Wert zusagen, den erwarteten anstreben, den optimistischen nie nennen. Wer den optimistischen nennt, hat den Termin bereits verloren.

Was die Prognose verschiebt

Die drei häufigsten Gründe, warum der tatsächliche Termin vom erwarteten abweicht:

Scope-Wachstum: Der Backlog wächst während der Arbeit — jede Iteration bringt neue Erkenntnisse und Wünsche
Velocity-Einbruch: Ferienzeit, Personalwechsel, technische Schulden, die eingelöst werden müssen
Unsichtbare Arbeit: Bugfixes, Support und Refactoring, die nicht als Story Points erscheinen

Burnup statt Burndown

Ein Burnup-Chart zeigt zwei Linien: erledigte Punkte und Gesamtumfang. Wächst der Umfang schneller als der Fortschritt, sieht man es sofort — ein Burndown versteckt das. Für Release-Prognosen ist das Burnup das ehrlichere Bild; in Flenio liefern Berichte beide Ansichten je Projekt.

Häufige Fragen

Wie bestimme ich die Schwankung?

Aus den letzten fünf Sprints: höchste minus tiefste Velocity, halbiert, geteilt durch den Durchschnitt. Bei 32/45/38/48/37 sind das (48−32)÷2÷40 = 20 %.

Was ist mit unschätzbaren Stories?

Ein Epic ohne Schätzung ist ein blinder Fleck in der Prognose. Grob schätzen (T-Shirt-Grössen in Punkte übersetzen) ist besser als weglassen — weglassen macht die Prognose systematisch zu optimistisch.

Wie oft die Prognose aktualisieren?

Nach jedem Sprint, in zwei Minuten: neuer Backlog-Stand, neue Velocity. Der Trend über mehrere Sprints ist wichtiger als der einzelne Wert.