Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Warum sich Product Owner bei der Bearbeitungsdauer von Features nicht auf die durchschnittliche Velocity verlassen sollten und was sie stattdessen tun können

November 27, 2021

Wann ist das Feature fertig?

Diese legitime Frage, die Stakeholder im Sprint Review stellen und welche regelmäßig Mitglieder des Scrum Teams zusammenzucken lässt, sollte jeder erfahrene Product Owner beantworten können.

Im Folgenden findest du Möglichkeiten, wie du diese Frage beantworten kannst. Diese Antworten haben sich bereits in der Praxis vieler Product Owner bewährt. Deshalb gebe ich sie auch in meinen Professional Scrum Trainings weiter.

Nehmen wir einmal an, das Feature, nach dem sich der Stakeholder erkundigt, besteht aus den ersten fünf grünen Einträgen im Product Backlog.

Backlog

In den letzten drei Sprints hat das Scrum Team einmal 10 Story Points, dann 20 Story Points und im letzten 8 Story Points erledigt. Im Durchschnitt also etwa 13. Beantwortet man die Frage, wann das Feature fertig ist, basierend auf dem Durchschnitt, lautet die Antwort "in zwei Sprints".

Diese Antwort ist allerdings in 1 von 32 Fällen richtig.

Warnung #1: Beantworte die Frage nicht basierend auf der durchschnittlichen Velocity

Warum ist das so?

Der Informatiker und Statistiker Dr. Sam L. Savage erklärt es in seinen Vorträgen wie folgt: Angenommen, es findet um 8:00 Uhr eine Besprechung statt, zu der 5 Personen eingeladen sind. Es müssen alle Teilnehmer anwesend sein, bevor die Besprechung beginnen kann. Nehmen wir weiter an, dass alle Teilnehmer im Durchschnitt pünktlich zu den Besprechungen erscheinen und dass die durchschnittliche Pünktlichkeit 50 % beträgt.

Was sind die Chancen, dass die Sitzung pünktlich beginnt?

Wenn im Durchschnitt alle Teilnehmer pünktlich erscheinen, könnte man davon ausgehen, dass die Besprechung mit einer durchschnittlichen Wahrscheinlichkeit pünktlich beginnen wird. Leider ist auch diese Antwort falsch.

Warum ist das so?

Wir können uns dies anhand von Münzwürfen erklären: Da jeder Eingeladene eine 50-prozentige Chance hat, pünktlich zu erscheinen, könnten wir das wie folgt auffassen: Ist ein bestimmter Teilnehmer pünktlich erschienen, bedeutet diese "Kopf", sonst "Zahl". Wenn wir jetzt berücksichtigen, dass die Besprechung nur dann beginnen kann, wenn alle Teilnehmer eintreffen, bedeutet das, dass wir 5 Mal in Folge Kopf werfen müssen. Diese Wahrscheinlichkeit beträgt (1/2)^5, also etwa 1 zu 32.

Der Durchschnitt ignoriert Unsicherheiten.

Wenn man die Beantwortung der Frage "Wann wird das Feature fertig sein?" nur auf eine einzige Zahl reduziert, ignoriert man alle Unbekannten und die Variabilität, die bei der Entwicklung des Features auftreten können. Erfahrene Product Owner beziehen die in der Produktentwicklung herrschende Unsicherheit in ihre Antwort mit ein.

Antwort #1: Basierend auf dem Kegel der Unsicherheiten

Sie bedienen sich dabei einem Vorgehen, welches sich in der Vorhersage von Hurrikans im Katastrophenschutz bewährt hat. Projiziert man Hurrikanvorhersagen auf eine Landkarte, sieht es ungefähr so aus wie ein Kegel. Der mögliche Korridor des Hurrikans ist zunächst recht eng und wird immer breiter, je weiter man in die Zukunft schaut. Meteorologen berechnen den Kegel anhand mathematischer Modelle, die die bisher gesammelten Wetterdaten berücksichtigen.

Als Product Owner können wir uns das Vorgehen zunutze machen, um die Unsicherheit in unserer Vorhersage zu visualisieren.

Die untere Seite des Kegels (grüne gestrichelte Linie) entspricht der Velocity von 20 aus dem zweiten Sprint. Die obere Seite des Kegels (rote gestrichelte Linie) entspricht der Velocity von 8 aus dem dritten Sprint. Der dadurch aufgespannte Kegel beschreibt basierend auf der vergangenen Fertigstellungsgeschwindigkeit, dass das Feature im besten Fall in zwei Sprints und im schlechtesten Fall in 4 Sprints fertig sein wird.

Cone of Uncertainty

Im Gegensatz zu Vorhersagen, welche auf dem Durchschnitt basieren (blaue gestrichelte Linie), visualisiert der Kegel der Unsicherheiten mögliche Fertigstellungstermine, basierend auf bisher gesammelten Daten des Teams.

Average

Eine Vorhersage mittels des Kegels der Unsicherheiten hilft Product Ownern die Frage, wann ein Feature fertig ist, durch die Angabe eines Bereichs möglicher Fertigstellungstermine zu beantworten. Dabei berücksichtigt die Antwort gleichzeitig die herrschende Unsicherheit in der Produktentwicklung, welcher das Team bis jetzt ausgesetzt war.

Antwort #2: Basierend auf Wahrscheinlichkeiten

Sollte die Visualisierung des Kegels der Unsicherheiten für die Beantwortung der Frage nicht detailliert genug sein, hat sich in den letzten Jahren für Product Owner bewährt, numerische Simulationen zu verwenden. Eine darauf basierende Prognose beschreibt eine Reihe von Eintrittswahrscheinlichkeiten, wann das Feature fertig sein könnte. Im Unterschied zum Kegel der Unsicherheiten beziehen Prognosen die Ungewissheit durch die Angabe von Wahrscheinlichkeit noch aussagekräftiger ein.

Wenn wir in unserem Beispiel das hervorragende Throughput-Forecaster-Tool von Troy Magennis und Adam Yuret auf Focused Objective heranziehen, dann erhalten wir die folgende Prognose:

Forecast

Die Frage, wann das Feature fertig ist, können wir detaillierter beantworten, indem wir sagen, dass wir mit großer Zuversicht denken, dass das Feature in den nächsten 4 Sprints fertiggestellt wird. Hierfür beträgt die Wahrscheinlichkeit bis zu 100 %. Nur mit Zuversicht können wir sagen, dass das Feature in den nächsten drei Sprints fertig wird. Dass das Feature in den nächsten zwei Sprints fertig wird, ist hingegen sehr unwahrscheinlich, da die Wahrscheinlichkeit dafür maximal 50 % beträgt.

Die Genauigkeit numerischer Simulationen kann erheblich verbessert werden, wenn wir noch weitere Daten, wie

  • die Velocity der letzten sieben Sprints,
  • die Häufigkeit, mit der Produkt-Backlog-Einträge zerteilt wurden, und
  • das Verhältnis, wie viel die Teammitglieder in diesem Team arbeiten

gesammelt haben.

Results

Warnung #2: Eine Prognose bleibt eine Prognose

Auch wenn man sich für die Beantwortung der Frage, wann das Feature fertig ist, nicht auf den Durchschnitt verlässt und stattdessen den Kegel der Unsicherheiten oder Wahrscheinlichkeitsverteilung heranzieht, sollte man eines niemals vergessen:

Alle Antworten sind nur Prognosen. Bei komplexer Arbeit ist nur eines gewiss: Was passieren wird, ist ungewiss.

 

Möchtest Du mehr erfahren?

Hoffentlich war dieser Artikel nützlich für Dich. Wie man Prognosen durchführt, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
 

Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert. 


👉 Hier geht zur Anmeldung.


What did you think about this post?