Wie Betterplan prognostiziert
„Wie lange dauert es, und was kostet es?“ ist die Frage, die in jedem Projekt immer wieder kommt. Die Antwort ist meist ungenügend und zu aufwendig. Betterplan geht davon aus, dass zwei Dinge reichen, damit sie leichter fällt: ein Backlog, das zu jedem Zeitpunkt abgeschätzt ist, und ein Team, das in Iterationen arbeitet. Beides lässt sich schwer von Hand durchhalten. Betterplan nimmt dir diese Arbeit ab. Stories ohne eigene Schätzung bekommen automatisch einen vorläufigen Wert, den Median aller Schätzungen (siehe Automatische Schätzung), du musst also nicht alles schätzen, und beim Abschließen einer Iteration hält es einen Snapshot fest. Diese Seite erklärt, wie daraus die Prognosen in Progress, Delivery Timeline und im Estimation Widget entstehen.
Die Zutaten
| Zutat | Woher sie kommt |
|---|---|
| Scope | Summe der Story Points aller User Stories (siehe Schätzen: die Grundlagen) |
| Erledigt | Punkte der gelieferten Stories |
| Velocity | Durchschnitt der Punkte, die die letzten drei abgeschlossenen Iterationen geliefert haben. Bis dahin gilt der Wert aus den Einstellungen |
| Scope-Zuwachs | Wie viele Punkte der Scope im Schnitt pro Iteration wächst, über dieselben drei Iterationen |
| Iterationslänge | Aus den Projekteinstellungen, Reiter Team |
Dass die Velocity ein Durchschnitt der letzten drei Iterationen ist, hat einen Grund: Ältere Iterationen sagen weniger über dein Team von heute aus. Der Hilfetext der Anwendung spricht an einer Stelle noch von einem Median, gerechnet wird mit dem Durchschnitt.
Von der Velocity zum Datum
Progress zieht den Zuwachs von der Velocity ab: Das Team liefert pro Iteration die Velocity, gleichzeitig wächst der Scope um den Zuwachs. Das Netto-Tempo ist der Unterschied. Die Restpunkte geteilt durch das Netto-Tempo, aufgerundet, ergeben die Zahl der Iterationen bis zum Ziel. Das ETA liegt so viele Iterationslängen hinter dem heutigen Stand.
Im Beispiel QuickCart: 283 Punkte Scope, 171 erledigt, also 112 Restpunkte. Bei einer Velocity von 21 und stabilem Scope sind das 112 / 21, aufgerundet 6 Iterationen. Bei zwei Wochen Iterationslänge liegt die ETA damit 12 Wochen nach heute (in den Beispieldaten am 8. Januar 2027). Ein Scope-Zuwachs macht das Netto-Tempo kleiner und das Datum später. Wächst der Scope so schnell wie die Velocity oder schneller, zeigt Betterplan keine Prognose, sondern den Hinweis, dass der Scope schneller wächst, als geliefert wird. Das Diagramm zeichnet höchstens sechs Prognosepunkte, auch wenn das Ziel weiter weg liegt: Die Linie nennt eine Richtung, keine Zusage für Iteration 40.
Von der Velocity zur Timeline
Die Delivery Timeline rechnet feiner: Die Dauer einer Story ist ihre Schätzung geteilt durch die Velocity, mal der Iterationslänge. Die Stories werden nach der globalen Priorität eingeplant: Was am weitesten fortgeschritten ist, kommt zuerst, innerhalb einer Stufe entscheidet die Reihenfolge im Backlog. Dabei laufen so viele Stories gleichzeitig, wie das Team in den vergangenen Iterationen im Schnitt parallel bearbeitet hat. Die Reihenfolge im Storyboard spielt dafür keine Rolle. Beide Prognosen beruhen auf denselben Zahlen und sollten deshalb zusammenpassen.
Und die Kosten?
Mit Budget und Kosten pro Iteration (Projekteinstellungen, Reiter Team) lässt sich der Prognose ein Preis geben. Das Estimation Widget zeigt den Restbetrag, die Timeline kann das Ende des Budgets als Marke einblenden.
Prognose für einen Ausschnitt
Mit einem Filter rechnen Progress und das Estimation Widget Scope, Erledigt und Restpunkte nur für die sichtbaren Stories neu, zum Beispiel für ein Release. Die Velocity bleibt dabei die des ganzen Projekts, deshalb weisen beide darauf hin, dass die Schätzung zu optimistisch sein kann. Die Delivery Timeline ignoriert Filter und zeigt immer das ganze Projekt.
Wie sicher ist die Prognose?
Eine Prognose ist so gut wie ihre Grundlage:
- Wenige Iterationen: Unter drei abgeschlossenen Iterationen hat die Velocity wenig Messwerte, Progress warnt dann.
- Dünne Schätzungen: Stories ohne eigene Schätzung zählen mit dem Median der vorhandenen Schätzungen. Er wird erfahrungsgemäß ab etwa 30 geschätzten Stories belastbar, und je mehr echte Schätzungen es gibt, desto weniger hängt die Zahl an ihm. Schätze Stories also, wenn sie reifen, spätestens auf dem Weg zu Bereit (siehe Automatische Schätzung). Das Backlog vor der Detailarbeit schätzt Rapid Estimation grob hoch.
- Streuung: Ob ein Termin hält, hängt auch davon ab, wie gleichmäßig Stories fertig werden. Das zeigen die Flow-Metriken mit dem 85. Perzentil.
Lies die Prognose deshalb als Spanne und nicht als Datum auf den Tag. Je öfter du Iterationen sauber abschließt, desto besser wird sie.