Schätzungen polarisieren in der agilen Softwareentwicklung. Ob es nun darum geht, dass Schätzungen zu ungenau sind und ob der Aufwand für die Schätzung gerechtfertigt ist, oder wie man ohne Schätzen einen Ausblick in die Zukunft geben kann: Die Gründe für kontroverse Diskussionen sind vielfältig. Doch was, wenn wir es schaffen, den Schätzaufwand zu minimieren und dabei trotzdem eine Zukunftsprognose erstellen zu können? Und was, wenn sich das Team am Ende sogar besser darauf konzentrieren kann, eine wertbringende und funktionierende Software agil zu entwickeln?

Vor gut 20 Jahren wurde das Agile Manifest veröffentlicht und fast zeitgleich wurde Scrum als agiles Framework populär. Auch heute gilt Scrum quasi als Standardmethode, um agile Software zu entwickeln. Und mit Agilität, Scrum und den Empowered Teams kam auch die Aufwandschätzung ins Team. Und das nicht nur einmal am Anfang eines Projekts, sondern immer und immer wieder – für jedes einzelne Feature und für jede einzelne Story. Die Entwickler sollten selbst abschätzen, wie lange etwas dauert, und diese Schätzung dann als Basis für ein Commitment in der Umsetzung verwenden. Was anfangs nach einer guten Idee klang, wurde für viele Entwickler immer mehr zur Belastung – und auch heute ist das Thema Schätzen eines der meistdiskutierten Themen in vielen agilen Teams.

Seit ein paar Jahren propagieren daher einige Agilisten das sogenannte #NoEstimates: Software zu entwickeln, ohne auf Schätzungen zurückzugreifen. Dafür gibt es folgende Gründe: Zum einen liegt es in der Natur des Schätzens, dass es am Anfang eines Vorhabens geschieht, wenn wir noch am wenigsten über eine Sache wissen. Ein weiteres Problem von Schätzungen ist, dass sie per Definition unscharf und ungenau sind. Dazu kommt oft, dass, sobald eine Zahl genannt wurde, das Phänomen des Anchoring zum Zug kommt. Das bedeutet, dass die erste Zahl, die genannt wird, die Wahrnehmung aller weiteren Zahlen beeinflusst. Lautet zum Beispiel eine erste Schätzung „fünf Tage“, empfinden wir alles, das darunter liegt, als schnell, alles darüber als langsam.

Aber warum schätzen viele Teams überhaupt? Kurz gesagt geht es meistens darum, dass man eine Vorhersage haben möchte, wann etwas geliefert wird und mit welchen Kosten zu rechnen ist. Doch dafür müssen wir eigentlich gar nicht schätzen. Viel nützlicher sind Prognosen, die wir aufgrund von Daten aus unserem aktuellen Kontext ableiten.

Der Unterschied von Schätzungen und Prognosen

Ein wesentlicher Unterschied zwischen Schätzungen und Prognosen ist, dass Schätzungen typischerweise auf diskreten Zahlenwerten gemacht werden. Das gilt auch, wenn wir die Schätzgrößen kodieren, zum Beispiel als T-Shirt-Größen wie M, L, S und so weiter.

Prognosen hingegen können zwar Zahlenwerte enthalten, sind aber in der Regel umfassender und beschreiben auch den Kontext sowie mögliche Szenarien. Eine Wettervorhersage enthält zum Beispiel neben den Temperaturwerten auch Aussagen darüber, ob eine Wetterlage stabil bleibt oder ob man besser doch den Regenschirm einpacken sollte, wenn man morgens das Haus verlässt.

Schätzungen werden oft aufgrund von subjektiven Erfahrungswerten gemacht, während wir bei Prognosen auf zeitlich gegliederte Messreihen oder sogar Simulationen zurückgreifen. Um die Zukunft vorherzusagen, sind beide Methoden nicht perfekt, Prognosen sind aber deutlich aussagekräftiger, da in ihnen Kontextinformationen und mögliche Weiterentwicklungen enthalten sind.

Zusätzlich wird bei Prognosen die Datengrundlage für die Vorhersage mitgeliefert, sodass deren Auswirkungen mitberücksichtigt werden können. Bei der oben genannten Wettervorhersage wird zum Beispiel erwähnt, wenn sich das Nordatlantiktief stark verändert. Übertragen auf die Softwareentwicklung könnten wir beispielsweise frühzeitig darauf achten, wann neue Versionen von Softwarepaketen oder Betriebssystemupdates erwartet werden und welchen Einfluss das auf unsere Produktentwicklung haben kann. Statt also Zeit zu investieren, um eine Schätzung auf eine einzige Zahl zu reduzieren, befassen wir uns besser mit Prognosen – und hier kommt #NoEstimates ins Spiel.

#NoEstimates heißt nicht, dass wir keinen Ausblick in die Zukunft wagen, sondern dass wir dafür ein effektiveres Mittel als eine auf eine Zahl reduzierte Schätzung verwenden. Denn es hat einen einfachen Grund, dass Schätzungen in der Softwareentwicklung nicht funktionieren: Softwareentwicklung ist ein komplexer Vorgang und komplexe Vorgänge können wir schlicht und einfach nicht schätzen. „Komplex“ heißt, dass wir Ursache und Wirkung nicht zuverlässig voraussehen können, sondern oft – wenn überhaupt – nur im Nachhinein feststellen können. Wir können zwar Hypothesen oder alternative Szenarien aufstellen, aber ob und welche dann eintreffen, können wir im Voraus nie zuverlässig sagen.

Reduce the waste – start working

Ein oft zitierter Satz im Zusammenhang mit dem Agilen Manifest ist: „Our primary measure of success is running software“. Dazu kommt einer der Leitsätze der lean-agilen Softwareentwicklung: „Reduce the waste“, oder auf Deutsch: „Wir reduzieren alle Tätigkeiten, die keinen oder wenig Wert haben...