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.
Erklärvideo zum Cone of Uncertainty
Dieses Video ist nur sichtbar, wenn Du angemeldet bist.
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:
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.
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.
Iterativ-inkrementelles Vorgehen
Beides gemeinsam lässt sich dann folgendermaßen darstellen.
Ungewissheit mit dem Burn-Down-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.
