Genaue Prognosen ohne Schätzung

Oft wird dem Team oder jemandem in der Rolle des Product Owners entweder die Frage gestellt: "Wann wird es fertig sein?" oder "Was wird zu <einem zukünftigen Datum> fertig sein?", und zur Beantwortung dieser Frage ist eine Prognose erforderlich. Dieser Blog zeigt eine alternative Methode der Prognose, die auf empirischen Daten beruht und die Schätzung ganz überspringt. In einem Folgeblog werde ich mich mit der Ordnung des Arbeitsrückstands befassen.

Um diese Fragen zu beantworten, muss das 'Es' (i) geschätzt und (ii) geordnet werden. Sowohl die Schätzung als auch das Ordnen der Artikel sind nicht umsonst! Die Schätzung erfordert wertvolle Zeit des Teams, Zeit, die es auch für die Schaffung von Mehrwert für den Kunden verwenden könnte. Das Führen einer aktuellen geordneten Artikelliste erfordert ständige Aufmerksamkeit, in der Regel von der Person, die die Rolle des Product Owners übernimmt. Eine Artikelbestellung ist zeitlich nicht stabil: sich ändernde oder abgelaufene Marktfenster beeinflussen die Bestellung.

Einführung

Es gibt mehrere Möglichkeiten, mit der Frage 'Wann ist es fertig?' umzugehen:

• Nicht antworten! Geben Sie stattdessen eine Erklärung darüber ab, welchen Service Sie von Ihrem Team erwarten können (SLA).
• Verwendung von Tools wie 'Velocity'- und 'Release Burn Down'-Diagrammen.
• Schätzung in Stunden.
• Nutzung der Historie des Teams zum Durchsatz: probabilistische Vorhersage.

Was die Schätzung und Planung so schwierig macht, sind die Unwägbarkeiten in der Arbeit, die Abhängigkeiten von anderen, die Annahmen darüber, wie das System derzeit funktioniert, die Annahmen darüber, wie die Arbeit erledigt wird, und viele andere, die ich vergessen habe zu erwähnen. Letztendlich sind wir daran interessiert, Vorhersagen zu treffen, die für unsere Kunden von Interesse sind. Ein guter Ansatz für die Schätzung in Story Points, der dem Team nicht zu viel Zeit raubt, findet sich in 'Tips for ScrumMasters: Estimate user stories outside Sprint Planning Meetings" [5]. Während viele Teams die Velocity für die Vorhersage verwenden und der Blog von Mike Cohn mit dem Titel 'Improving On Traditional Release Burn Down Chart' [1] einen effektiven Weg für den Umgang mit Schwankungen in der 'Velocity' bietet, handelt es sich dabei um einen 'White Box'-Ansatz. Damit meine ich, dass er Annahmen über die Arbeitsweise des Teams enthält. Ein alternativer Ansatz besteht darin, eine 'Black Box'-Ansicht zu wählen und dabei alle Annahmen über die Arbeitsweise des Teams zu eliminieren. Dies kann entweder durch die Verwendung der Zykluszeit ("Zeit zwischen den Momenten, in denen der Kunde etwas erhält") oder des Durchsatzes ("Die Anzahl der Dinge, die der Kunde pro Woche erhält") geschehen. Eine sehr gute Einführung in die Prognose auf der Grundlage von Zykluszeiten finden Sie in [2].

Durchsatz

Nennen wir das "Zeug", das der Kunde will, "Stories". Dann ist der Durchsatz gleich der Anzahl der Stories, die alle zwei Wochen an den Kunden geliefert werden.

Die Magie besteht darin, Daten zu verwenden, die dem Team bereits zur Verfügung stehen und die auf der Geschichte beruhen. Empirische Daten. Zählen Sie zu diesem Zweck einfach die Anzahl der gelieferten Geschichten. Mit 10-20 Messungen lassen sich bereits vernünftige Prognosen erstellen (siehe [3] für weitere Einzelheiten). Das Beispiel auf der rechten Seite zeigt Durchsatzdaten, die für ein Team im Laufe von 12 Monaten gesammelt wurden. Es zeigt, wie oft ein bestimmter Durchsatz auftritt. Die in diesem Beispiel gesammelten Daten lauten: 3, 3, 4, 4, 7, 5, 1, 11, 5, 6, 3, 6, 6, 5, 4, 10, 4, 5, 8, 2, 4, 12, 5 Jede Zahl entspricht der Anzahl der in diesem bestimmten Zeitraum gelieferten Storys. Es ist wichtig zu beachten, dass diese Zahlen keine Zufallszahlen sind. Sie spiegeln die Art der Kundenanfragen, den Umfang der Anfragen und vielleicht auch die Art und Weise, wie sie bereits aufgeteilt wurden, wider. Darüber hinaus spiegeln diese Zahlen auch - auf komplizierte Weise - wider, wie das Team arbeitet, welche Abhängigkeiten es möglicherweise hat und andere Faktoren. Egal, wie kompliziert sie sind, wir brauchen die Details nicht zu kennen oder irgendeinen Faktor, den wir übersehen haben. All dies spiegelt sich in der Verteilung der Zahlen wider (wie oft tritt ein bestimmter Durchsatz auf).

Vorhersage

Mit Hilfe von Troy Magennis' Throughput Forecaster [4] werden wir die Zahlenfolge aus dem vorherigen Abschnitt in eine Prognose umwandeln. Wir nehmen zwei Anwendungsfälle als Beispiel: (a) Wann werden 60 Artikel fertig sein? Und (b) wie viele Aufgaben werden in 3 Sprints erledigt? Folgen Sie den Schritten:

1. Laden Sie das Arbeitsblatt herunter,
2. Kopieren Sie die Reihenfolge der Durchsatzzahlen und fügen Sie sie in das Arbeitsblatt 'Durchsatzstichproben' ein,
3. Verwenden Sie das Arbeitsblatt 'Prognose', um das Datum für den Beginn der Prognose (24.10.2017), die Länge des Sprints (14 Tage), den Durchsatz 'Daten' und die Anzahl der Elemente (60) einzugeben, für die Sie die Prognose erhalten möchten,
4. Lesen Sie die Prognose mit der gewünschten Konfidenzstufe ab,
5. Optional können Sie die Anzahl der zu erledigenden Aufgaben prognostizieren, indem Sie die Anzahl der Sprints angeben, die Sie vorausschauen möchten.

Akkurate Aussagen

Auf der Grundlage einer beobachteten Abfolge von Durchsatzzahlen kann man eine Prognose erstellen. Mit dem gewonnenen Einblick können wir genaue Aussagen machen.

Wann wird es fertig sein?

Aus Schritt 4 erhalten wir das rechts abgebildete Ergebnis. Aus der Tabelle können wir die genaue Aussage ableiten:

In 85 von 100 Fällen werden wir 60 Geschichten vor dem 24. April 2018 liefern.

Das ist sehr wirkungsvoll, weil das Team völlig transparent macht, wozu es in der Lage ist, während es das Risiko dem Kunden überlässt. Dieser weiß, wie viel Risiko er bereit ist, einzugehen. Die Tabelle zeigt, dass eine Lieferung vor dem 8. Mai 2018 fast sicher ist (95 % Konfidenz), der 24. April 2018 vernünftig und Ende März 2018 unrealistisch. Es ist Sache des Antragstellers, des Interessenvertreters oder des Produkteigentümers, diese Informationen klug zu nutzen. Nur sie wissen, welchen Wert das Versprechen eines frühen Termins hat und welches Risiko sie bereit sind, einzugehen.

Was soll getan werden?

Schritt 5 sagt uns mit Sicherheit die Anzahl der innerhalb eines bestimmten Zeitraums gelieferten Arbeitspakete. Daraus können wir die Aussage ableiten

In 85 von 100 Fällen werden wir 13 Aufgaben erledigen, und in 95 von 100 Fällen werden wir 11 Aufgaben erledigen.

In der Praxis habe ich die Erfahrung gemacht, dass diese Art von Anweisung nützlich ist, wenn wir einen festen Umfang haben und die Frage 'Wann wird es erledigt sein?' beantworten müssen.

• Es gibt eine Frist und das Team muss wissen: "Was wird voraussichtlich fertiggestellt werden?
• wie viele Optionen müssen wir im Voraus haben (oder wie viele ausgefeilte Geschichten müssen wir im Voraus haben).

Die Fertigstellung von 11 Elementen in 3 Sprints ist eine fast sichere Sache, während 23 höchst unwahrscheinlich und unrealistisch sind. Außerdem zeigt die obige Tabelle, dass 13 verfeinerte Stories ausreichen.

Fazit

Die probabilistische Vorhersage auf der Grundlage des Durchsatzes ist eine gute Alternative zu traditionelleren Methoden. Sie:

• Beruht auf empirischen Daten,
• verwendet Daten, die leicht zu beschaffen sind,
• bietet die Möglichkeit, sehr genaue Aussagen zu machen,
• ist modell- und evidenzbasiert,
• ist etwas, das Sie schon morgen nutzen können!

Referenzen

[1] Mike Cohn, 'Improving On Traditional Release Burn Down Charts', Mountain Goat Software, Improving on traditional release burndown charts [2] Dimitar Bakardzhiev, '#NoEstimates Project Planning Using Monte Carlo Simulation', Veröffentlicht auf InfoQ, 2014, No Estimates monte carlo [3] Pieter Rijken, Jasper Sonnevelt, 'Probabilistic forecasting using empirical task data for a Lean process', Error Estimates In Probabilistic Forecasting.pdf [4] Troy Magennis, 'Single Feature Forecast Spreadsheet', Focused Objective, Single feature forecast spreadsheet [5] Marco Mulder, 'Tips for ScrumMasters: Estimate user stories outside Sprint Planning Meetings', Xebia Blog, 2009, Tipps für ScrumMaster schätzen User Stories außerhalb von Sprint Planning Meetings/