5 2 Votes
Artikel-Rating

Der Cone of Uncertainty geht auf eine Studie der NASA zurück, bei der sie herausfand, dass die Schätzungen darüber, wie lange ein Projekt dauern wird, stark auseinander gehen.

Tatsächlich waren die anfänglichen Schätzungen (vor Beginn des Projektes) bis zum Vierfachen größer bzw. kleiner als die später gemessene, tatsächliche Dauer des Projektes. Ein Projekt, das am Ende 1 Monat benötigte, wurde zuvor mit einer Dauer von 1 Woche bzw. 4 Monaten geschätzt.

Gründe für die Ungewissheit in Projekten

Die Gründe für die großen Schwankungen bei den Schätzungen lassen sich auf die vielen Ungewissheiten zu Beginn eines Projektes (oder einer Produktentwicklung) zurückführen. Im agilen Kontext nennen wir dieses Phänomen auch Komplexität. Sie entsteht beispielsweise durch:

  • Unterschiedliche Anforderungen (im Vergleich zu anderen, bisherigen Projekten)

  • Unterschiedliche oder neue Teammitglieder (im Vergleich zu anderen, bisherigen Projekten)

  • Neue und/oder bisher noch nicht verwendete Technologien oder Hardware (im Vergleich zu anderen, bisherigen Projekten)

  • Andere Prioritäten und Voraussetzungen (im Vergleich zu anderen, bisherigen Projekten)

Scrums Antwort auf den Cone of Uncertainty

Nun möchte ich Dir zeigen, welche Antwort das agile Framework Scrum auf das Problem gibt, welches durch den Cone of Uncertainty sichtbar wird. Und zwar ist die Antwort auf große Ungewissheit ein iterativ-inkrementelles Vorgehen. Im Grunde gibt Scrum also gleich zwei Antworten auf hohe Komplexität.

Iteratives Vorgehen

Die erste Antwort auf das Problem des Cone of Uncertainty ist iteratives Vorgehen.

Iteration bedeutet, dass Du in Deiner Produktentwicklung kurze und immer gleich strukturierte Arbeitszyklen durchläufst. Am Ende jeder Iteration kannst Du gemeinsam mit Deinem Scrum Team überprüfen, ob das, was Ihr getan habt, einen Fortschritt in die richtige Richtung war. Darüber hinaus könnt Ihr die neuen Informationen, die Ihr über das Produkt und Euer Umfeld herausgefunden habt, auswerten.

Diese Informationen können Ihr dann dazu nutzen, um Euren Plan oder Euer weiteres Vorgehen entsprechend anzupassen. Mit jeder weiteren Iteration wird der Anteil an Ungewissheit und Komplexität kleiner.

Iteratives Vorgehen - Cone of Uncertainty
  • Scrum nennt diese Iterationen auch Sprints. Ausführlich habe ich das iterative Vorgehen von Scrum in meinem Artikel Was ist ein Sprint? dargestellt.

Inkrementelles Vorgehen

Die zweite Antwort, die Scrum auf den Cone of Uncertainty gibt, ist inkrementelles Vorgehen.

Inkrementelles Vorgehen bedeutet, dass sich Euer Produkt immer in einem nutzbaren Zustand befindet. Wird es um neue Funktionen erweitert, müssen diese Funktionen (spätestens) am Ende einer Iteration fertig sein.

Der Grund hierfür ist relativ einfach: Ein Produkt, das im besten Fall bereites live beim Kunden eingesetzt wird, erhöht die Transparenz.

Probleme und Herausforderungen werden dadurch unmittelbar sichtbar und können umgehend behoben werden. Oder anders gesagt: Iterationen allein sind wenig hilfreich, wenn die Transparenz (aufgrund eines unfertigen Produktes) minimal ist.

Inkrementelles Vorgehen - Cone of Uncertainty

Iterativ-inkrementelles Vorgehen

Beides gemeinsam lässt sich dann folgendermaßen darstellen.

Iterativ-inkrementelles Vorgehen - Cone of Uncertainty

Ungewissheit mit dem Burndown Chart visualisieren

Darüber hinaus ist es bei großer Ungewissheit wenig hilfreich mit festen Deadlines zu arbeiten.

Um dem Cone of Uncertainty Rechnung zu tragen, kannst Du als Product Owner in der Kommunikation mit Stakeholdern auf die sogenannte Velocity Range zurückgreifen.

Statt (nur) mit einer durchschnittlichen Sprint-Velocity ein fixes Enddatum vorherzusagen, ermöglicht Dir die Velocity Range einen Zielkorridor, der auf der maximalen und minimalen Velocity und dem Median-Wert Deines Scrum Teams basiert.

Release Burndown Chart mit Velocity Range