Monte Carlo Forecasting für die Terminplanung in Azure DevOps

Wie die Monte Carlo Simulation tatsächlich funktioniert

Das ist ein Bootstrap-Resampling Ihrer eigenen Historie, keine statistische Kurvenanpassung. Für jeden der 10.000 Durchläufe bewegt sich die Simulation Schritt für Schritt durch das Forecast-Fenster und zieht dabei jeweils zufällig (mit Zurücklegen) einen der abgeschlossenen Sprints Ihres Teams, um dessen Anzahl fertiggestellter Elemente zur laufenden Summe zu addieren. Wiederholt man das 10.000-mal, ergibt die Streuung der Ergebnisse den Forecast. Das läuft auf der Azure DevOps-Historie, die die Erweiterung bereits liest, ohne Ihre Daten zuerst in eine andere Plattform zu exportieren, ohne ein zu konfigurierendes Personal Access Token und ohne ein dazwischengeschaltetes, beim Publisher gehostetes Analytics-Backend. Die Simulation ist außerdem deterministisch: Die Zufallsziehungen werden aus Ihrer Sprint-Historie, dem Forecast-Fenster und der Anzahl der Durchläufe abgeleitet, sodass zwei Durchläufe mit denselben Eingaben denselben P50/P70/P85/P95-Bereich liefern. Der Bereich verändert sich nur, wenn sich Ihr zugrunde liegender Durchsatz ändert. Fällt das Ende des Forecast-Fensters nicht genau auf eine Sprintgrenze, wird dieser übrige Teilzeitraum anteilig berücksichtigt statt als vollständiger Sprint gezählt, damit das Modell an den Rändern nicht überzählt.

Perzentil-Forecasts richtig lesen: warum ein Bereich einem einzelnen Termin überlegen ist

Jeder Forecast liefert vier Konfidenzstufen aus denselben 10.000 simulierten Durchläufen, jede mit der Bedeutung „so viele Elemente oder mehr, mindestens so oft“:

• P95, Sehr wahrscheinlich: die Zahl, die Sie mit einer Wahrscheinlichkeit von 95 Prozent erreichen oder übertreffen. Meist die kleinste, sicherste Zusage im Bereich.
• P85, Wahrscheinlich: die Stufe, die die meisten Teams für einen Termin nutzen, den sie einem Stakeholder gegenüber vertreten.
• P70, Möglich: ein brauchbarer Mittelweg, häufiger richtig als falsch, aber kein sicheres Versprechen.
• P50, Münzwurf: die Zahl, die die Hälfte der simulierten Durchläufe erreicht hat und die Hälfte nicht. Nützlich als ambitioniertes Ziel, riskant als Zusage.

Wie viele bis zu einem Termin, im Vergleich zu: Wann sind N Elemente fertig

Das sind zwei unterschiedliche Fragen, und die Simulation hat für jede einen eigenen Modus. „Wie viele?“ nimmt einen Zieltermin (standardmäßig 30 Tage in der Zukunft) und liefert für jede Konfidenzstufe, wie viele Backlog-Elemente Sie bis dahin voraussichtlich fertigstellen; nutzen Sie diesen Modus, wenn der Termin feststeht und der Umfang die offene Frage ist, etwa bei einem Release-Termin oder einem vertraglichen Meilenstein. „Wann ist es fertig?“ nimmt eine Backlog-Größe, etwa die verbleibenden Elemente eines Epics, und liefert stattdessen einen Zeitraum; nutzen Sie diesen Modus, wenn der Umfang feststeht und der Termin die offene Frage ist. Weil sich die Richtung der Frage umdreht, dreht sich auch das Perzentil um: Bei „Wann ist es fertig?“ ist P50 der früheste, optimistischste Termin und P95 der späteste, vorsichtigste. Ist ein Backlog so groß, dass ein Teil der 10.000 simulierten Durchläufe die Zielanzahl innerhalb des Forecast-Horizonts nicht erreicht, meldet das Tool den Anteil, der nicht fertig wurde, statt stillschweigend anzunehmen, dass jeder Durchlauf abgeschlossen wurde, damit ein breiter Zeitraum nicht mit einer falsch sicheren Zahl überdeckt wird.

Was der Forecast braucht, bevor die Zahlen aussagekräftig sind

Ein Monte Carlo Forecast ist nur so vertrauenswürdig wie die abgeschlossene Sprint-Historie, aus der er resampelt. Öffnen Sie den Forecast für ein Team, listet die Sprintauswahl Ihre zehn zuletzt abgeschlossenen Sprints auf und wählt standardmäßig die sechs jüngsten für den ersten Forecast aus; Sie können die Auswahl von Hand ändern, was wichtig ist, wenn einer dieser Sprints ein echter Ausreißer war, etwa eine Ferienwoche oder eine Reorganisation, die Sie aus dem Resampling ausschließen möchten. Der aktuell laufende Sprint wird aus dieser Standardauswahl automatisch entfernt: Ein Resampling aus einem noch offenen, unvollständigen Sprint würde den gesamten Forecast mit einer Durchsatzzahl nach unten ziehen, die noch nicht zu Ende gezählt ist. Kann ein von Ihnen ausgewählter Sprint nicht geladen werden, weist die Ansicht offen darauf hin ("only X of Y requested sprints loaded") statt still auf Basis einer kleineren Stichprobe zu forecasten und das als vollständig auszugeben. Ein Team mit erst ein oder zwei abgeschlossenen Sprints erhält ebenfalls einen Forecast, aber der Bereich bleibt breit, bis mehr Historie vorliegt; die Simulation kann keine Sicherheit erzeugen, die Ihr Team sich noch nicht erarbeitet hat.